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

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: Move pg_attribute.attcompression to earlier in struct for reduced size?
Дата
Msg-id CA+TgmoaOnOem=5dacsWqhWHoRO9tvnOuAnseWnR3_mYG-8J5Dg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Move pg_attribute.attcompression to earlier in struct for reduced size?  (Dilip Kumar <dilipbalaut@gmail.com>)
Ответы Re: Move pg_attribute.attcompression to earlier in struct for reduced size?  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: Move pg_attribute.attcompression to earlier in struct for reduced size?  (Peter Geoghegan <pg@bowt.ie>)
Список 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 по дате отправления:

Предыдущее
От: Julien Rouhaud
Дата:
Сообщение: Re: sync request forward function ForwardSyncRequest() might hang for some time in a corner case?
Следующее
От: Greg Sabino Mullane
Дата:
Сообщение: Re: Speed up pg_checksums in cases where checksum already set