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