Re: Move pg_attribute.attcompression to earlier in struct for reduced size?
Justin Pryzby <pryzby@telsasoft.com>
From: Justin Pryzby <pryzby@telsasoft.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Michael Paquier <michael@paquier.xyz>, Andres Freund <andres@anarazel.de>, pgsql-hackers@postgresql.org, Dilip Kumar <dilipbalaut@gmail.com>, Robert Haas <robertmhaas@gmail.com>
Date: 2021-05-26T19:32:38Z
Lists: pgsql-hackers
On Wed, May 26, 2021 at 11:13:46AM -0400, Tom Lane wrote: > Michael Paquier <michael@paquier.xyz> writes: > > Ah, the parallel with reltablespace and default_tablespace at database > > level is a very good point. It is true that currently the code would > > assign attcompression to a non-zero value once the relation is defined > > depending on default_toast_compression set for the database, but > > setting it to 0 in this case would be really helpful to change the > > compression methods of all the relations if doing something as crazy > > as a VACUUM FULL for this database. Count me as convinced. > > Here's a draft patch series to address this. > > 0001 removes the relkind checks I was questioning originally. > As expected, this results in zero changes in check-world results. > > 0002 is the main change in the semantics of attcompression. > This does change the results of compression.sql, but in what > seem to me to be expected ways: a column's compression option > is now shown in \d+ output only if you explicitly set it. > > 0003 further removes pg_dump's special handling of > default_toast_compression. I don't think we need that anymore. > AFAICS its only effect would be to override the receiving server's > default_toast_compression setting for dumped/re-loaded data, which > does not seem like a behavior that anyone would want. > > Loose ends: > > * I've not reviewed the docs fully; there are likely some more > things that need updated. > > * As things stand here, once you've applied ALTER ... SET COMPRESSION > to select a specific method, there is no way to undo that and go > back to the use-the-default setting. All you can do is change to > explicitly select the other method. Should we invent "ALTER ... > SET COMPRESSION default" or the like to cover that? (Since > DEFAULT is a reserved word, that exact syntax might be a bit of > a pain to implement, but maybe we could think of another word.) > > * I find GetDefaultToastCompression() annoying. I do not think > it is project style to invent trivial wrapper functions around > GUC variable references: it buys nothing while requiring readers > to remember one more name than they would otherwise. Since there > are only two uses remaining, maybe this isn't very important either > way, but I'm still inclined to flush it. +1 It existed when default_toast_compression was a text string. Since e5595de03, it's an enum/int/char, and serves no purpose. -- Justin
Commits
-
Remove forced toast recompression in VACUUM FULL/CLUSTER
- dbab0c07e5ba 14.0 landed
-
Rethink definition of pg_attribute.attcompression.
- e6241d8e030f 14.0 landed
-
Fix memory leak when de-toasting compressed values in VACUUM FULL/CLUSTER
- fb0f5f0172ed 14.0 landed
-
Re-order pg_attribute columns to eliminate some padding space.
- f5024d8d7b04 14.0 landed
-
Add more TAP tests for pg_dump with attribute compression
- 63db0ac3f9e6 14.0 cited