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: Andres Freund <andres@anarazel.de>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Dilip Kumar <dilipbalaut@gmail.com>, pgsql-hackers <pgsql-hackers@postgresql.org>, Robert Haas <robertmhaas@gmail.com>
Date: 2021-05-27T02:07:53Z
Lists: pgsql-hackers 
On Wed, May 26, 2021 at 06:54:15PM -0700, Andres Freund wrote:
> Oh, it'll definitely be more expensive in that case - but that seems
> fair game. What I was wondering about was whether VACUUM FULL would be
> measurably slower, because we'll now call toast_get_compression_id() on
> each varlena datum. It's pretty easy for VACUUM FULL to be CPU bound
> already, and presumably this'll add a bit.

This depends on the number of attributes, but I do see an extra 0.5%
__memmove_avx_unaligned_erms in reform_and_rewrite_tuple() for a
normal VACUUM FULL with a 1-int-column relation on a perf profile,
with rewrite_heap_tuple eating most of it as in the past, so that's
within the noise bandwidth if you measure the runtime.  What would be
the worst case here, a table with one text column made of non-NULL
still very short values?
--
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