Horton

Re: Move pg_attribute.attcompression to earlier in struct for reduced size?

Michael Paquier <michael@paquier.xyz>

View thread View on postgr.es
From: Michael Paquier <michael@paquier.xyz>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Andres Freund <andres@anarazel.de>, Dilip Kumar <dilipbalaut@gmail.com>, pgsql-hackers <pgsql-hackers@postgresql.org>, Robert Haas <robertmhaas@gmail.com>
Date: 2021-05-27T01:00:16Z
Lists: pgsql-hackers 
On Wed, May 26, 2021 at 08:35:46PM -0400, Tom Lane wrote:
> Andres Freund <andres@anarazel.de> writes:
> > The efficiency bit is probably going to be swamped by the addition of
> > the compression handling, given the amount of additional work we're now
> > doing in in reform_and_rewrite_tuple().
> 
> Only if the user has explicitly requested a change of compression, no?

Andres' point is that we'd still initialize and run through
values_free at the end of reform_and_rewrite_tuple() for each tuple
even if there no need to do so.  Well, we could control the
initialization and the free() checks at the end of the routine if we
know that there has been at least one detoasted value, at the expense
of making the code a bit less clear, of course.
--
Michael

Commits

  1. Remove forced toast recompression in VACUUM FULL/CLUSTER

  2. Rethink definition of pg_attribute.attcompression.

  3. Fix memory leak when de-toasting compressed values in VACUUM FULL/CLUSTER

  4. Re-order pg_attribute columns to eliminate some padding space.

  5. Add more TAP tests for pg_dump with attribute compression