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
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? |