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

From Robert Haas
Subject Re: adding 'zstd' as a compression algorithm
Date
Msg-id CA+TgmoaEY=yptCb5t=yGOe9n7dL0Qsd9Z5a3LCgmw_xBm+6vyA@mail.gmail.com
Whole thread Raw
In response to Re: adding 'zstd' as a compression algorithm  (David Steele <david@pgmasters.net>)
Responses Re: adding 'zstd' as a compression algorithm  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Tue, Feb 15, 2022 at 7:09 PM David Steele <david@pgmasters.net> wrote:
> I'm not sure that this is entirely true. lz4 is available on most
> non-EOL distros but you don't need to look to far to find a distro that
> does not have it. So, choosing lz4 by default could impact binary
> portability. Of course, there are lots of other factors that impact
> binary portability, e.g. collations, but this would add one more.
>
> This is even more true for zstd since it is not as ubiquitous as lz4. In
> fact, it is not even included with base RHEL8. You need to install EPEL
> to get zstd.

Yeah, I agree. One thing I was thinking about but didn't include in
the previous email is that if we did choose to make something like LZ4
the default, it would presumably only be the default on builds that
include LZ4 support. Other builds would need to use something else,
unless we just chose to make LZ4 a hard requirement, which would be
bolder than we usually are. And that has the consequence that you
mention. It's something we should consider as we think about changing
defaults.

> Having said all that, I'm absolutely in favor of adding zstd to Postgres
> as an optional compression format.

Cool.

-- 
Robert Haas
EDB: http://www.enterprisedb.com



pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: adding 'zstd' as a compression algorithm
Next
From: Tom Lane
Date:
Subject: Re: adding 'zstd' as a compression algorithm