| From: | Michael Paquier <michael(at)paquier(dot)xyz> |
|---|---|
| To: | Andrey Borodin <x4mmm(at)yandex-team(dot)ru> |
| Cc: | Justin Pryzby <pryzby(at)telsasoft(dot)com>, Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com>, Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, Peter Geoghegan <pg(at)bowt(dot)ie>, Andres Freund <andres(at)anarazel(dot)de> |
| Subject: | Re: Different compression methods for FPI |
| Date: | 2021-06-17 06:57:26 |
| Message-ID: | YMryVgORHbhRGSDp@paquier.xyz |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Thu, Jun 17, 2021 at 11:45:37AM +0500, Andrey Borodin wrote:
> Konstantin, Daniil and Justin are working on compressing libpq
> [0]. That would make walsender compress WAL automatically.
> And we (at least I and Dan) are inclined to work on compressing
> on-disk WAL as soon as libpq compression will be committed.
What's the relationship between libpq and WAL? Just the addition of
zstd in the existing dependency chain?
> Zstd is much better at compressing long data sequences than lz4.
That's my impression.
> I'm sure we will need such codec in core one day.
>
> Because compressing sequence of zeroes is cheap, even for pglz. But
> we still need to support 'no compression at all', this mode benefits
> from hole-in-a-page a lot. Until we send and store WAL uncompressed,
> of cause.
I am not sure, but surely this will come up in future discussions as a
separate problem.
--
Michael
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Fabien COELHO | 2021-06-17 07:00:50 | Re: pgbench logging broken by time logic changes |
| Previous Message | Andrey Borodin | 2021-06-17 06:45:37 | Re: Different compression methods for FPI |