| From: | Andres Freund <andres(at)anarazel(dot)de> |
|---|---|
| To: | Michael Paquier <michael(at)paquier(dot)xyz> |
| 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 02:24:13 |
| Message-ID: | 20220216022413.gzbhlbfwjgvcv3bq@alap3.anarazel.de |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hi,
On 2022-02-16 09:58:44 +0900, Michael Paquier wrote:
> 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.
For backups it's pretty obviously zstd imo. At the lower levels it achieves
considerably higher compression ratios while still being vastly faster than
gzip. Without even using the threaded compression support the library has.
For something like wal_compression it'd be a harder question.
Greetings,
Andres Freund
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Kasahara Tatsuhito | 2022-02-16 02:27:58 | Small and unaffected typo in pg_logical_slot_get_changes_guts() |
| Previous Message | Michael Paquier | 2022-02-16 02:23:17 | Re: pgsql: Add TAP test to automate the equivalent of check_guc |