Re: Add LZ4 compression in pg_dump

From: gkokolatos(at)pm(dot)me
To: Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com>
Cc: Michael Paquier <michael(at)paquier(dot)xyz>, Justin Pryzby <pryzby(at)telsasoft(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org, Rachel Heaton <rachelmheaton(at)gmail(dot)com>
Subject: Re: Add LZ4 compression in pg_dump
Date: 2023-01-23 17:31:55
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

------- Original Message -------
On Friday, January 20th, 2023 at 12:34 AM, Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com> wrote:

> On 1/19/23 18:55, Tomas Vondra wrote:
> > Hi,
> >
> > On 1/19/23 17:42, gkokolatos(at)pm(dot)me wrote:
> >
> > > ...
> > >
> > > Agreed. It was initially submitted as one patch. Then it was requested to be
> > > split up in two parts, one to expand the use of the existing API and one to
> > > replace with the new interface. Unfortunately the expansion of usage of the
> > > existing API requires some tweaking, but that is not a very good reason for
> > > the current patch set. I should have done a better job there.
> > >
> > > Please find v22 attach which combines back 0001 and 0002. It is missing the
> > > documentation that was discussed above as I wanted to give a quick feedback.
> > > Let me know if you think that the combined version is the one to move forward
> > > with.
> >
> > Thanks, I'll take a look.
> After taking a look and thinking about it a bit more, I think we should
> keep the two parts separate. I think Michael (or whoever proposed) the
> split was right, it makes the patches easier to grok.

Please find attached v23 which reintroduces the split.

0001 is reworked to have a reduced footprint than before. Also in an attempt
to facilitate the readability, 0002 splits the API's and the uncompressed
implementation in separate files.

> While reading the thread, I also noticed this:
> > By the way, I think that this 0002 should drop all the default clauses
> > in the switches for the compression method so as we'd catch any
> > missing code paths with compiler warnings if a new compression method
> > is added in the future.
> Now I realize why there were "not yet implemented" errors for lz4/zstd
> in all the switches, and why after removing them you had to add a
> default branch.
> We DON'T want a default branch, because the idea is that after adding a
> new compression algorithm, we get warnings about switches not handling
> it correctly.
> So I guess we should walk back this change too :-( It's probably easier
> to go back to v20 from January 16, and redo the couple remaining things
> I commented on.

No problem.

> FWIW I think this is a hint that adding LZ4/ZSTD options, in 5e73a6048,
> but without implementation, was not a great idea. It mostly defeats the
> idea of getting the compiler warnings - all the places already handle
> PG_COMPRESSION_LZ4/PG_COMPRESSION_ZSTD by throwing a pg_fatal. So you'd
> have to grep for the options, inspect all the places or something like
> that anyway. The warnings would only work for entirely new methods.
> However, I now also realize the compressor API in 0002 replaces all of
> this with calls to a generic API callback, so trying to improve this was
> pretty silly from me.
> Please, fix the couple remaining details in v20, add the docs for the
> callbacks, and I'll try to polish it and get it committed.

Thank you very much. Please find an attempt to comply with the requested
changes in the attached.

> regards
> --
> Tomas Vondra
> EnterpriseDB:
> The Enterprise PostgreSQL Company

Attachment Content-Type Size
v23-0001-Prepare-pg_dump-internals-for-additional-compres.patch text/x-patch 13.1 KB
v23-0002-Introduce-Compress-and-Compressor-API-in-pg_dump.patch text/x-patch 68.4 KB
v23-0003-Add-LZ4-compression-to-pg_dump.patch text/x-patch 29.3 KB

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2023-01-23 17:38:20 Re: run pgindent on a regular basis / scripted manner
Previous Message Andres Freund 2023-01-23 17:31:36 Re: run pgindent on a regular basis / scripted manner