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

From David Steele
Subject Re: adding 'zstd' as a compression algorithm
Date
Msg-id 4c9e7967-9966-ba69-90bb-59fdf6fdbfe3@pgmasters.net
Whole thread Raw
In response to Re: adding 'zstd' as a compression algorithm  (Peter Geoghegan <pg@bowt.ie>)
Responses Re: adding 'zstd' as a compression algorithm
List pgsql-hackers
On 2/15/22 16:10, Peter Geoghegan wrote:
> On Tue, Feb 15, 2022 at 12:00 PM Robert Haas <robertmhaas@gmail.com> wrote:
>> I'm not sure I completely follow this. There are cases where we use
>> compression algorithms for internal purposes, and we can change the
>> defaults without users knowing or caring. For example, we could decide
>> that LZ4-compressing FPIs in WAL records is a sensible default and
>> just start doing it, and users need not care. 

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.

>> But backups are
>> different, because when you pg_basebackup -Ft, you get .tar or .tar.gz
>> or .tar.lz4 files which we don't give you tools to extract.
> 
> What I meant is that you're buying into an ecosystem by choosing to
> use a tool like pgBackrest. That might not be the right thing to do
> universally, but it comes pretty close. You as a user are largely
> deferring to the maintainers and their choice of defaults. Not
> entirely, of course, but to a significant degree, especially in
> matters like this. There aren't that many dimensions to the problem
> once the question of compatibility is settled (it's settled here
> because you've already bought into a tool that requires the library as
> standard, say).

As much as we would like to, we have not changed the default compression 
for pgBackRest. lz4 and zstd are both optional at build time since they 
are not always available (though lz4 is getting close). So we have left 
gzip as the default, though a lot of that has to do with maintaining 
compatibility with prior versions of pgBackRest.

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

Regards,
David



pgsql-hackers by date:

Previous
From: Nathan Bossart
Date:
Subject: USE_BARRIER_SMGRRELEASE on Linux?
Next
From: Masahiko Sawada
Date:
Subject: Fix a comment in worker.c