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

Поиск
Список
Период
Сортировка
От Peter Geoghegan
Тема Re: Move pg_attribute.attcompression to earlier in struct for reduced size?
Дата
Msg-id CAH2-WznwfNu77VTJK5-6gNAD2EWiX6YK1Hcamfz4OrHg0hKkGw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Move pg_attribute.attcompression to earlier in struct for reduced size?  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: Move pg_attribute.attcompression to earlier in struct for reduced size?  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
On Thu, May 27, 2021 at 7:25 AM Robert Haas <robertmhaas@gmail.com> wrote:
> 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.

Your argument would be more convincing (at least to me) if we really
did expect users to want to pick and choose, based on natural
variations in datasets that make switching to *either* potentially
yield a real benefit. It is my understanding that lz4 is pretty much
superior to pglz by every relevant measure, though, so I'm not sure
that that argument can be made. At the same time, users tend to only
care specifically about things that are real step changes -- which I
don't think this qualifies as. Users will go out of their way to get one of
those, but otherwise won't bother.

Perhaps there is a practical argument in favor of VACUUM FULL reliably
recompressing using lz4 on upgrade, where that's the user's stated
preference. It's not self-evident that VACUUM FULL must or even should
do that, at least to me. I'm not suggesting that there must not be
such an argument. Just that I don't think that anybody has made such
an argument.

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

I don't think that follows at all.


--
Peter Geoghegan



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: storing an explicit nonce
Следующее
От: Andres Freund
Дата:
Сообщение: Re: storing an explicit nonce