Re: Compressed TOAST Slicing
Paul Ramsey <pramsey@cleverelephant.ca>
From: Paul Ramsey <pramsey@cleverelephant.ca>
To: Tomas Vondra <tomas.vondra@2ndquadrant.com>
Cc: Michael Paquier <michael@paquier.xyz>,
Andres Freund <andres@anarazel.de>,
PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>,
Regina Obe <r@pcorp.us>
Date: 2019-03-13T16:05:29Z
Lists: pgsql-hackers
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Add support for partial TOAST decompression
- 4d0e994eed83 12.0 landed
-
Remove remaining hard-wired OID references in the initial catalog data.
- 3aa0395d4ed3 12.0 cited
-
Rephrase references to "time qualification".
- ebcc7bf949ba 12.0 cited
> On Mar 13, 2019, at 8:25 AM, Paul Ramsey <pramsey@cleverelephant.ca> wrote: > > > >> On Mar 13, 2019, at 3:09 AM, Tomas Vondra <tomas.vondra@2ndquadrant.com> wrote: >> >> On 3/13/19 3:19 AM, Michael Paquier wrote: >>> On Tue, Mar 12, 2019 at 07:01:17PM -0700, Andres Freund wrote: >>>> I don't think this is even close to popular enough to incur the >>>> maybe of a separate function / more complicated interface. By this >>>> logic we can change basically no APIs anymore. >>> >>> Well, if folks here think that it is not worth worrying about, I won't >>> cry on that either. If only the original API is kept, could it just >>> be possible to make it extensible with some bits16 flags then? Adding >>> only a boolean is not really appealing. >> >> In my experience "extensible" APIs with bitmasks are terrible - it's a >> PITA to both use them and maintain stuff that calls them. That is not to >> say there is no use for that design pattern, or that I like API breaks. >> But I very much prefer when an API change breaks things, alerting me of >> places that may require attention. >> >> And I'm with Andres here about the complexity being rather unwarranted >> here - I don't think we've changed pglz API in years (if ever), so what >> is the chance we'd actually benefit from the extensibility soon? > > I’m just going to saw the baby in half, retaining the old pglz_decompress() signature and call into a pglz_decompress_checked() signature that allows one to optionally turn off the checking at the end (which is all the split boolean argument does, so probably my current name is not the best name for that argument). > > Scream madly at me if you consider this inappropriate. Here is a new (final?) patch that adds the extra signature and for good measure includes the minor changes to varlena.c necessary to turn on slicing behaviour for left() and starts_with() (text_substring() already slices by default, just to no avail without this patch) P.