Re: adding 'zstd' as a compression algorithm

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: David Steele <david(at)pgmasters(dot)net>
Cc: 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 01:35:20
Message-ID: CA+TgmoaEY=yptCb5t=yGOe9n7dL0Qsd9Z5a3LCgmw_xBm+6vyA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Feb 15, 2022 at 7:09 PM David Steele <david(at)pgmasters(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2022-02-16 01:56:15 Re: adding 'zstd' as a compression algorithm
Previous Message Michael Paquier 2022-02-16 00:58:44 Re: adding 'zstd' as a compression algorithm