From: | Michael Paquier <michael(at)paquier(dot)xyz> |
---|---|
To: | Adrian Klaver <adrian(dot)klaver(at)aklaver(dot)com> |
Cc: | Mladen Gogala <gogala(dot)mladen(at)gmail(dot)com>, pgsql-general(at)lists(dot)postgresql(dot)org |
Subject: | Re: Force re-compression with lz4 |
Date: | 2021-10-19 04:00:59 |
Message-ID: | YW5C+wFHLW1YyEty@paquier.xyz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Mon, Oct 18, 2021 at 08:01:04AM -0700, Adrian Klaver wrote:
> Not sure how much this applies to the Postgres usage of lz4. As I understand
> it, this is only used internally for table compression. When using pg_dump
> compression gzip is used. Unless you pipe plain text output through some
> other program.
More precisely, LZ4 applies to the compression of toastable values in
14~. In 15~, we can already use it for WAL and the compression of
full-page writes.
It is worth noting that there are extra patches floating around to add
more LZ4 pluggability to pg_dump (I think this has not been published
yet), pg_receivewal (published) and base backups through the
replication protocol (published). I have seen rather good numbers
when it came to WAL, FWIW. Even if the compression ratio was a bit
less than pglz, it was much faster.
--
Michael
From | Date | Subject | |
---|---|---|---|
Next Message | David G. Johnston | 2021-10-19 04:02:23 | Re: JSON query |
Previous Message | David G. Johnston | 2021-10-19 03:47:58 | Re: Where is the tsrange() function documented? |