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 YKMXVHCoNGZ61E9q@paquier.xyz
обсуждение исходный текст
Ответ на Re: Move pg_attribute.attcompression to earlier in struct for reduced size?  (Andres Freund <andres@anarazel.de>)
Ответы Re: Move pg_attribute.attcompression to earlier in struct for reduced size?  (Michael Paquier <michael@paquier.xyz>)
Список pgsql-hackers
On Mon, May 17, 2021 at 02:28:57PM -0700, Andres Freund wrote:
> On 2021-05-17 17:06:32 -0400, Tom Lane wrote:
>> Putting it just after attalign seems like a reasonably sane choice
>> from the standpoint of grouping things affecting physical storage;
>> and as you say, that wins from the standpoint of using up alignment
>> padding rather than adding more.
>
> Makes sense to me.

+1.

>> Personally I'd think the most consistent order in that area would
>> be attbyval, attalign, attstorage, attcompression; but perhaps it's
>> too late to swap the order of attstorage and attalign.
>
> Given that we've put in new fields in various positions on a fairly
> regular basis, I don't think swapping around attalign, attstorage would
> cause a meaningful amount of additional pain.  Personally I don't have a
> preference for how these are ordered.

If you switch attcompression, I'd say to go for the others while on
it.  It would not be the first time in history there is a catalog
version bump between betas.
--
Michael

Вложения

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

Предыдущее
От: Peter Smith
Дата:
Сообщение: Re: "ERROR: deadlock detected" when replicating TRUNCATE
Следующее
От: "Pengchengliu"
Дата:
Сообщение: RE: Re: Parallel scan with SubTransGetTopmostTransaction assert coredump