| From: | Michael Paquier <michael(at)paquier(dot)xyz> |
|---|---|
| To: | Andres Freund <andres(at)anarazel(dot)de> |
| Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Peter Geoghegan <pg(at)bowt(dot)ie>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: adding 'zstd' as a compression algorithm |
| Date: | 2022-02-16 00:58:44 |
| Message-ID: | YgxMRKT990GeZx+B@paquier.xyz |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Tue, Feb 15, 2022 at 01:42:55PM -0800, Andres Freund wrote:
> I think well before removing stuff we should default to decent compression
> algorithms. E.g. -Z/--compress should probably not continue to use gzip if
> better things are available.
Which one of lz4 or zstd would it be though? LZ4 is light on CPU, and
compresses less than zstd which is more CPU intensive with more
compression, so the choice does not look that straight-forward to me.
Both of them are better than zlib, still they are less available on
the platforms Postgres needs to provide support for. It does not seem
really intuitive to me to have different defaults depending on the
build options provided, either :/
Saying that, I'd like to think that zstd would still be a better
default choice than LZ4.
--
Michael
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Robert Haas | 2022-02-16 01:35:20 | Re: adding 'zstd' as a compression algorithm |
| Previous Message | Tomas Vondra | 2022-02-16 00:39:37 | Re: Column Filtering in Logical Replication |