Re: remove ATTRIBUTE_FIXED_PART_SIZE

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: remove ATTRIBUTE_FIXED_PART_SIZE
Дата
Msg-id 19251.1534770876@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: remove ATTRIBUTE_FIXED_PART_SIZE  (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>)
Ответы Re: remove ATTRIBUTE_FIXED_PART_SIZE
Список pgsql-hackers
Peter Eisentraut <peter.eisentraut@2ndquadrant.com> writes:
>> I don't think the tuple packing issue has to do with the tuple
>> descriptor code.  The tuple descriptors already use allocations of size
>> sizeof(FormData_pg_attribute) (CreateTemplateTupleDesc), just the memcpy
>> and memset calls use (potentially) less.  That might have saved a few
>> bytes for omitting the varlena fields, but I don't think it affects
>> alignment correctness.  If we, say, added a trailing char field now, the
>> only thing this code
> ... the only thing the current code would accomplish is not copying the
> last three padding bytes, which might even be slower than copying all four.

But, if the varlena fields are all null, those bytes might not be there
... at least, not according to valgrind.

I agree this is all moot as long as there's no pad bytes.  What I'm
trying to figure out is if we need to put in place some provisions
to prevent there from being pad bytes at the end of any catalog struct.
According to what Andres is saying, it seems like we do (at least for
ones with varlena fields).

            regards, tom lane


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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: [FEATURE PATCH] pg_stat_statements with plans (v02)
Следующее
От: Tom Lane
Дата:
Сообщение: Re: ALTER TABLE on system catalogs