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+TgmoapZRTVXtiJYY-bH4=S9OQvrSHe72Xx7udO_6bdPM+Ecg@mail.gmail.com
Whole thread Raw
In response to Re: adding 'zstd' as a compression algorithm  (Andres Freund <andres@anarazel.de>)
Responses Re: adding 'zstd' as a compression algorithm  (Andres Freund <andres@anarazel.de>)
List pgsql-hackers
On Tue, Feb 15, 2022 at 2:54 PM Andres Freund <andres@anarazel.de> wrote:
> There's a difference between downloading a source tarball of 1.5x the size,
> and 3x the decompression cost (made up numbers), because the cost of either is
> not a relevant factor. I think basebackups are a different story.

To be clear, I'm not saying that people shouldn't choose to adopt the
new stuff. I'm just saying that many of them won't, for various
reasons, including inertia. There may come a point when we want to
make a push to remove obsolete stuff, but I think what is far more
important right now is making the new stuff available.

> Yea, we should really default to lz4 in initdb when available. Expecting users
> to know about magic incantation to get often vastly superior performance isn't
> a good approach. And it even makes initdb itself faster, because it turns out
> we compress enough that the cpu cycles for it are a measurable factor.

I don't mind if you want to propose a patch for that, but it seems
like a separate topic from this thread.

> IMO zstd has pretty much won the "gzip" type usecase of compression. Even
> prior lz4 uses have even been converted to it because it's often cheap enough.

You know more about this than I do...

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



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: adding 'zstd' as a compression algorithm
Next
From: Jean Baro
Date:
Subject: Re: WIP: System Versioned Temporal Table