Re: Move pg_attribute.attcompression to earlier in struct for reduced size? - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Move pg_attribute.attcompression to earlier in struct for reduced size?
Date
Msg-id 1264790.1623209541@sss.pgh.pa.us
Whole thread Raw
In response to Re: Move pg_attribute.attcompression to earlier in struct for reduced size?  (Michael Paquier <michael@paquier.xyz>)
Responses Re: Move pg_attribute.attcompression to earlier in struct for reduced size?
List pgsql-hackers
Michael Paquier <michael@paquier.xyz> writes:
> On Tue, Jun 08, 2021 at 10:39:24AM -0400, Alvaro Herrera wrote:
>> Maybe at this point reverting is the only solution.

> That's a safe bet at this point.  It would be good to conclude this
> one by beta2 IMO.

I still think it's a really dubious argument that anybody would want to
incur a VACUUM FULL to force conversion to a different compression method.

I can imagine sometime in the future where we need to get rid of all
instances of pglz so we can reassign that compression code to something
else.  But would we insist on a mass VACUUM FULL to make that happen?
Doubt it.  You'd want a tool that would make that happen over time,
in the background; like the mechanisms that have been discussed for
enabling checksums on-the-fly.

In the meantime I'm +1 for dropping this logic from VACUUM FULL.
I don't even want to spend enough more time on it to confirm the
different overhead measurements that have been reported.

            regards, tom lane



pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: Move pg_attribute.attcompression to earlier in struct for reduced size?
Next
From: Amit Kapila
Date:
Subject: Re: logical decoding bug: segfault in ReorderBufferToastReplace()