Re: remove ATTRIBUTE_FIXED_PART_SIZE

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>
Cc: Andres Freund <andres(at)anarazel(dot)de>, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: remove ATTRIBUTE_FIXED_PART_SIZE
Date: 2018-08-20 13:14:36
Message-ID: 19251.1534770876@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2018-08-20 13:34:50 Re: ALTER TABLE on system catalogs
Previous Message Tom Lane 2018-08-20 13:09:04 Re: [FEATURE PATCH] pg_stat_statements with plans (v02)