Re: adding 'zstd' as a compression algorithm

On Tue, Feb 15, 2022 at 2:54 PM Andres Freund <andres(at)anarazel(dot)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