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

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Move pg_attribute.attcompression to earlier in struct for reduced size?
Дата
Msg-id 1264790.1623209541@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Move pg_attribute.attcompression to earlier in struct for reduced size?  (Michael Paquier <michael@paquier.xyz>)
Ответы Re: Move pg_attribute.attcompression to earlier in struct for reduced size?
Список pgsql-hackers
Michael Paquier <michael@paquier.xyz> writes:
> On Tue, Jun 08, 2021 at 10:39:24AM -0400, Alvaro Herrera wrote:
>> Maybe at this point reverting is the only solution.

> That's a safe bet at this point.  It would be good to conclude this
> one by beta2 IMO.

I still think it's a really dubious argument that anybody would want to
incur a VACUUM FULL to force conversion to a different compression method.

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.

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.

            regards, tom lane



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

Предыдущее
От: Michael Paquier
Дата:
Сообщение: Re: Move pg_attribute.attcompression to earlier in struct for reduced size?
Следующее
От: Amit Kapila
Дата:
Сообщение: Re: logical decoding bug: segfault in ReorderBufferToastReplace()