Hi, On 2019-08-02 19:00:39 +0200, Tomas Vondra wrote: > On Fri, Aug 02, 2019 at 09:39:48AM -0700, Andres Freund wrote: > > Hi, > > > > On 2019-08-02 20:40:51 +0500, Andrey Borodin wrote: > > > We have some kind of "roadmap" of "extensible pglz". We plan to > > > provide implementation on Novembers CF. > > > > I don't understand why it's a good idea to improve the compression side > > of pglz. There's plenty other people that spent a lot of time > > developing better compression algorithms. > > > > Isn't it beneficial for existing systems, that will be stuck with pglz > even if we end up adding other algorithms?
Why would they be stuck continuing to *compress* with pglz? As we fully retoast on write anyway we can just gradually switch over to the better algorithm. Decompression speed is another story, of course. Here's what I had a few years back: https://www.postgresql.org/message-id/20130621000900.GA12425%40alap2.anarazel.de see also https://www.postgresql.org/message-id/20130605150144.GD28067%40alap2.anarazel.de I think we should refresh something like that patch, and: - make the compression algorithm GUC an enum, rename - add --with-system-lz4 - obviously refresh the copy of lz4 - drop snappy Greetings, Andres Freund