Horton

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

Tom Lane <tgl@sss.pgh.pa.us>

View thread View on postgr.es
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Michael Paquier <michael@paquier.xyz>
Cc: Andres Freund <andres@anarazel.de>, pgsql-hackers@postgresql.org, Dilip Kumar <dilipbalaut@gmail.com>, Robert Haas <robertmhaas@gmail.com>
Date: 2021-05-21T15:01:03Z
Lists: pgsql-hackers

Attachments

Michael Paquier <michael@paquier.xyz> writes:
> This is still an open item.  FWIW, I can get behind the reordering
> proposed by Tom for the consistency gained with pg_type, leading to
> the attached to reduce the size of FormData_pg_attribute from 116b to
> 112b.

I think we need to do more than that.  It's certainly not okay to
leave catalogs.sgml out of sync with reality.  And maybe I'm just
an overly anal-retentive sort, but I think that code that manipulates
tuples ought to match the declared field order if there's not some
specific reason to do otherwise.  So that led me to the attached.

It was a good thing I went through this code, too, because I noticed
one serious bug (attcompression not checked in equalTupleDescs) and
another thing that looks like a bug: there are two places that set
up attcompression depending on

    if (rel->rd_rel->relkind == RELKIND_RELATION ||
        rel->rd_rel->relkind == RELKIND_PARTITIONED_TABLE)

This seems fairly nuts; in particular, why are matviews excluded?

			regards, tom lane

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