| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Michael Paquier <michael(at)paquier(dot)xyz> |
| Cc: | Andres Freund <andres(at)anarazel(dot)de>, Dilip Kumar <dilipbalaut(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Robert Haas <robertmhaas(at)gmail(dot)com> |
| Subject: | Re: Move pg_attribute.attcompression to earlier in struct for reduced size? |
| Date: | 2021-05-27 04:11:38 |
| Message-ID: | 1687119.1622088698@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 Wed, May 26, 2021 at 11:34:53PM -0400, Tom Lane wrote:
>> So maybe we should just dump the promise that VACUUM FULL will recompress
>> everything? I'd be in favor of that actually, because it seems 100%
>> outside the charter of either VACUUM FULL or CLUSTER.
> Hmm. You are right that by default this may not be worth the extra
> cost. We could make that easily an option, though, for users ready to
> accept this cost. And that could be handy when it comes to a
> database-wise VACUUM.
AFAIR, there are zero promises about how effective, or when effective,
changes in SET STORAGE will be. And the number of complaints about
that has also been zero. So I'm not sure why we need to do more for
SET COMPRESSION. Especially since I'm unconvinced that recompressing
everything just to recompress everything would *ever* be worthwhile.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Amit Kapila | 2021-05-27 04:13:07 | Re: Parallel Inserts in CREATE TABLE AS |
| Previous Message | Dilip Kumar | 2021-05-27 04:10:08 | Re: Decoding speculative insert with toast leaks memory |