Re: remove ATTRIBUTE_FIXED_PART_SIZE - Mailing list pgsql-hackers

From Tom Lane
Subject Re: remove ATTRIBUTE_FIXED_PART_SIZE
Date
Msg-id 19251.1534770876@sss.pgh.pa.us
Whole thread Raw
In response to Re: remove ATTRIBUTE_FIXED_PART_SIZE  (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>)
Responses Re: remove ATTRIBUTE_FIXED_PART_SIZE
List 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 by date:

Previous
From: Tom Lane
Date:
Subject: Re: [FEATURE PATCH] pg_stat_statements with plans (v02)
Next
From: Tom Lane
Date:
Subject: Re: ALTER TABLE on system catalogs