Re: adding 'zstd' as a compression algorithm - Mailing list pgsql-hackers

From Andres Freund
Subject Re: adding 'zstd' as a compression algorithm
Date
Msg-id 20220216022413.gzbhlbfwjgvcv3bq@alap3.anarazel.de
Whole thread Raw
In response to Re: adding 'zstd' as a compression algorithm  (Michael Paquier <michael@paquier.xyz>)
Responses Re: adding 'zstd' as a compression algorithm  (Michael Paquier <michael@paquier.xyz>)
List 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



pgsql-hackers by date:

Previous
From: John Naylor
Date:
Subject: Re: Mark all GUC variable as PGDLLIMPORT
Next
From: Kasahara Tatsuhito
Date:
Subject: Small and unaffected typo in pg_logical_slot_get_changes_guts()