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

Поиск
Список
Период
Сортировка
От Michael Paquier
Тема Re: Move pg_attribute.attcompression to earlier in struct for reduced size?
Дата
Msg-id YMF0cDCFxe4w3bTx@paquier.xyz
обсуждение исходный текст
Ответ на 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?  (Michael Paquier <michael@paquier.xyz>)
Список pgsql-hackers
On Tue, Jun 08, 2021 at 11:32:21PM -0400, Tom Lane wrote:
> 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.

Well, I can imagine that some people could afford being more
aggressive here even if it implies some downtime and if they are not
willing to afford the deployment of a second instance for a
dump/restore or a logirep setup.

(The parallel with data checksums is partially true, as you can do a
switch of checksums with physical replication as the page's checksums
are only written when pushed out of shared buffers, not when they are
written into WAL.  This needs a second instance, of course.)

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

Agreed.  It looks like we are heading toward doing just that for this
release.
--
Michael

Вложения

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

Предыдущее
От: torikoshia
Дата:
Сообщение: Re: RFC: Logging plan of the running query
Следующее
От: Justin Pryzby
Дата:
Сообщение: Re: alter table set TABLE ACCESS METHOD