From: Tom Lane <tgl@sss.pgh.pa.us>
To: Michael Paquier <michael@paquier.xyz>
Cc: Andres Freund <andres@anarazel.de>
Cc: pgsql-hackers@postgresql.org, Dilip Kumar <dilipbalaut@gmail.com>
Cc: Robert Haas <robertmhaas@gmail.com>
Subject: Re: Move pg_attribute.attcompression to earlier in struct for reduced size?
Date: Mon, 24 May 2021 01:05:07 -0400
Message-ID: <851353.1621832707@sss.pgh.pa.us> (raw)
In-Reply-To: <YKsusgc6Wcii+1lI@paquier.xyz>
References: <20210517204803.iyk5wwvwgtjcmc5w@alap3.anarazel.de>
<2854987.1621285592@sss.pgh.pa.us>
<20210517212857.qyk4fxykfbxhmxof@alap3.anarazel.de>
<YKMXVHCoNGZ61E9q@paquier.xyz>
<YKdT5ZM5OInCsDkM@paquier.xyz>
<3962395.1621609263@sss.pgh.pa.us>
<626613.1621787110@sss.pgh.pa.us>
<YKsusgc6Wcii+1lI@paquier.xyz>
Michael Paquier <michael@paquier.xyz> writes:
> On Sun, May 23, 2021 at 12:25:10PM -0400, Tom Lane wrote:
>> While I've not actually tested this, it seems to me that we could
>> just drop these relkind tests altogether. It won't hurt anything
>> to set up attcompression in relation descriptors where it'll never
>> be consulted.
> Wouldn't it be confusing to set up attcompression for relkinds without
> storage, like views?
No more so than setting up attstorage, surely.
>> ... I think we
>> should redefine attcompression as "ID of a compression method
>> to use, or \0 to select the prevailing default. Ignored if
>> attstorage does not permit the use of compression". This would
>> result in approximately 99.44% of all columns just having zero
>> attcompression, greatly simplifying the tupdesc setup code, and
>> also making it much easier to flip an installation over to a
>> different preferred compression method.
> Would there be any impact when it comes to CTAS or matviews where the
> current code assumes that the same compression method as the one from
> the original value gets used, making the creation of the new relation
> cheaper because there is less de-toasting and re-toasting?
I'd still envision copying the source attcompression setting in such
cases. I guess the question is (a) does that code path actually
recompress values that have the "wrong" compression, and (b) if it
does, is that wrong? If you think (a) is correct behavior, then
I don't see why refreshing after changing default_toast_compression
shouldn't cause that to happen.
regards, tom lane
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: tgl@sss.pgh.pa.us, michael@paquier.xyz, andres@anarazel.de, dilipbalaut@gmail.com, robertmhaas@gmail.com
Subject: Re: Move pg_attribute.attcompression to earlier in struct for reduced size?
In-Reply-To: <851353.1621832707@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox