Re: [HACKERS] Custom compression methods
Robert Haas <robertmhaas@gmail.com>
Hi,
Does this patch need to do something about ExtractReplicaIdentity()?
If there are compressed fields in the tuple being built, can we rely
on the decompression engine being available at the time we need to do
something with the tuple?
More generally, I think it would be good to divide up 0001 into at
least 3 parts:
- The first part would invent HeapTupleGetRawDatum() and
HeapTupleHeaderGetRawDatum() and use them in place of the existing
functions everywhere that it's safe to do so. The current patch just
switches to using PointerGetDatum() but I think we should instead add
something like static inline Datum
HeapTupleHeaderGetRawDatum(HeapTupleHeader tuple) {
Assert(!HeapTupleHeaderHasExternal(tup)); return
PointerGetDatum(tuple); } This provides some type safety while being
just as fast as a direct use of PointerGetDatum() in optimized code. I
think that the Assert will have to be ripped out if we proceed with
the other patches, but if we can have it at this stage, so much the
better. I think this patch should also invent
PG_RETURN_HEAPTUPLEHEADER_RAW and likewise use that where appropriate
- including, I think, in place of cases that are now using
PG_RETURN_DATUM(HeapTupleGetDatum(...)). All of these changes make
sense from an efficiency standpoint apart from any possible
definitional changes.
- The second part would optimize code that the first part cannot
safely convert to use the "raw" versions. For example, the changes to
ExecEvalRow() can go in this part. You can view this part as getting
rid of calls to HeapTupleGetDatum(), HeapTupleHeaderGetDatum(), and/or
PG_RETURN_HEAPTUPLE() that couldn't be changed categorically, but can
be changed if we make some other code changes. These changes, too, can
potentially be justified on performance grounds independently of
anything else.
- Then we could maybe have some more patches that make other kinds of
preparatory changes. I'm not too sure exactly what should go in here,
or whether it should be 1 patch or several or maybe 0. But if there's
preparatory stuff that's potentially separately committable and not
the same as the stuff above, then it should go into patches here.
- The last patch would actually change the rule for composite datums.
One advantage of this is that if we have to revert the last patch for
some reason we are not ripping the entire thing, churning the code
base and widely-used APIs for everyone. Another advantage is that
getting those first two patches committed or even just applied locally
on a branch would, at least IMHO, make it a lot simpler to see what
potential problem spots remain - and by "problem" I mean mostly from a
performance point of view.
--
Robert Haas
EDB: http://www.enterprisedb.com
Commits
-
docs: Update TOAST storage docs for configurable compression.
- e8c435a824e1 14.0 landed
-
Further tweaking of pg_dump's handling of default_toast_compression.
- 54bb91c30e39 14.0 landed
-
Fix interaction of TOAST compression with expression indexes.
- 5db1fd7823a1 14.0 landed
-
Tidy up more loose ends related to configurable TOAST compression.
- e5595de03ec6 14.0 landed
-
Short-circuit slice requests that are for more than the object's size.
- 063dd37ebc76 14.0 landed
-
Mostly-cosmetic adjustments of TOAST-related macros.
- aeb1631ed207 14.0 landed
-
Remove useless configure probe for <lz4/lz4.h>.
- 2c75f8a612b2 14.0 landed
-
Error on invalid TOAST compression in CREATE or ALTER TABLE.
- a4d5284a10b5 14.0 landed
-
docs: Fix omissions related to configurable TOAST compression.
- 24f0e395ac58 14.0 landed
-
More code cleanup for configurable TOAST compression.
- 226e2be3876d 14.0 landed
-
Bring configure support for LZ4 up to snuff.
- 4d399a6fbeb7 14.0 landed
-
Make compression.sql regression test independent of default.
- fd1ac9a54896 14.0 landed
-
Use valid compression method in brin_form_tuple
- 882b2cdc08c4 14.0 landed
-
Fix up pg_dump's handling of per-attribute compression options.
- aa25d1089ac0 14.0 landed
-
Allow configurable LZ4 TOAST compression.
- bbe0a81db69b 14.0 landed
-
Fix inconsistencies in the code
- 6b8548964bcc 13.0 cited
-
Mostly-cosmetic improvements in memory chunk header alignment coding.
- f65d21b25808 11.0 cited
-
Allow numeric to use a more compact, 2-byte header in many cases.
- 145343534c15 9.1.0 cited