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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Michael Paquier <michael(at)paquier(dot)xyz>
Cc: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, Robert Haas <robertmhaas(at)gmail(dot)com>, Dilip Kumar <dilipbalaut(at)gmail(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Move pg_attribute.attcompression to earlier in struct for reduced size?
Date: 2021-06-09 03:32:21
Message-ID: 1264790.1623209541@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Michael Paquier <michael(at)paquier(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Kapila 2021-06-09 03:33:17 Re: logical decoding bug: segfault in ReorderBufferToastReplace()
Previous Message Michael Paquier 2021-06-09 03:24:57 Re: Move pg_attribute.attcompression to earlier in struct for reduced size?