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

From Robert Haas
Subject Re: Move pg_attribute.attcompression to earlier in struct for reduced size?
Date
Msg-id CA+TgmoaOnOem=5dacsWqhWHoRO9tvnOuAnseWnR3_mYG-8J5Dg@mail.gmail.com
Whole thread Raw
In response to Re: Move pg_attribute.attcompression to earlier in struct for reduced size?  (Dilip Kumar <dilipbalaut@gmail.com>)
Responses Re: Move pg_attribute.attcompression to earlier in struct for reduced size?
Re: Move pg_attribute.attcompression to earlier in struct for reduced size?
List pgsql-hackers
On Thu, May 27, 2021 at 10:18 AM Dilip Kumar <dilipbalaut@gmail.com> wrote:
> > [ shrug... ]  I think the history of the SET STORAGE option teaches us
> > that there is no such requirement, and you're inventing a scenario that
> > doesn't exist in the real world.
>
> But can we compare SET STORAGE with SET compression?  I mean storage
> just controls how the data are stored internally and there is no
> external dependency.  But if we see the compression it will have a
> dependency on the external library.  So if the user wants to get rid
> of the dependency on the external library then IMHO, there should be
> some way to do it by recompressing all the data.

TBH, I'm more concerned about the other direction. Surely someone who
upgrades from an existing release to v14 and sets their compression
method to lz4 is going to want a way of actually converting their data
to using lz4. To say that nobody cares about that is to deem the
feature useless. Maybe that's what Tom thinks, but it's not what I
think.

-- 
Robert Haas
EDB: http://www.enterprisedb.com



pgsql-hackers by date:

Previous
From: Julien Rouhaud
Date:
Subject: Re: sync request forward function ForwardSyncRequest() might hang for some time in a corner case?
Next
From: Greg Sabino Mullane
Date:
Subject: Re: Speed up pg_checksums in cases where checksum already set