From: | Michael Paquier <michael(at)paquier(dot)xyz> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
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-10 02:09:52 |
Message-ID: | YMF0cDCFxe4w3bTx@paquier.xyz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Jun 08, 2021 at 11:32:21PM -0400, Tom Lane wrote:
> 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.
Well, I can imagine that some people could afford being more
aggressive here even if it implies some downtime and if they are not
willing to afford the deployment of a second instance for a
dump/restore or a logirep setup.
(The parallel with data checksums is partially true, as you can do a
switch of checksums with physical replication as the page's checksums
are only written when pushed out of shared buffers, not when they are
written into WAL. This needs a second instance, of course.)
> 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.
Agreed. It looks like we are heading toward doing just that for this
release.
--
Michael
From | Date | Subject | |
---|---|---|---|
Next Message | Justin Pryzby | 2021-06-10 02:35:06 | Re: alter table set TABLE ACCESS METHOD |
Previous Message | torikoshia | 2021-06-10 02:09:22 | Re: RFC: Logging plan of the running query |