Обсуждение: Tuple alignment

Why do we require that t_hoff is MAXALIGNed? ISTM that if the first 
field in a tuple doesn't require alignment, it could be stored 
immediately after the null bitmap, without padding.

--   Heikki Linnakangas  EnterpriseDB   http://www.enterprisedb.com

Heikki Linnakangas <heikki@enterprisedb.com> writes:
> Why do we require that t_hoff is MAXALIGNed? ISTM that if the first 
> field in a tuple doesn't require alignment, it could be stored 
> immediately after the null bitmap, without padding.

Then the intra-tuple alignment would be unpredictable.

The OID trick doesn't work very well either.
        regards, tom lane

"Tom Lane" <tgl@sss.pgh.pa.us> writes:

> Heikki Linnakangas <heikki@enterprisedb.com> writes:
>> Why do we require that t_hoff is MAXALIGNed? ISTM that if the first 
>> field in a tuple doesn't require alignment, it could be stored 
>> immediately after the null bitmap, without padding.
>
> Then the intra-tuple alignment would be unpredictable.

At first I thought that was a killer problem too. But on further thought I
could only think of one thing that actually depends on consistent intra-tuple
alignment: the cache offset in the tupledesc used by heaptuple.c. It's
probably too gross to consider but in fact we could work around this problem.

At the limit we could keep 8 cache offsets for the 8 possible alignments of
t_hoff. But I think we could be cleverer. If we kept track of the "normal"
offset for the maxaligned t_hoff then any field would only ever be up to 7
bytes offset from that. As you meet fields with larger and larger alignment
eventually fields would be back to their normal alignment if you mean a
maxaligned field. So the "correct" place to find any field is

cached normal alignment -  (t_hoff aligned to largest alignment seen on earlier fields - t_hoff)

This depends on an assumption which is true in C but perhaps not for Postgres
datatypes: sizeof(datatype) is an integral multiple of alignof(datatype) for
all data types.


I'm not sure it's worth bothering with this given that the space savings
possible is bounded to a fixed alignment per tuple. For tuples with 8 fields
or under there's usually going to be no savings at all. I just thought I would
get this down and in the mail archives before I forget it.

> The OID trick doesn't work very well either.

expn "OID trick"?

--  Gregory Stark EnterpriseDB          http://www.enterprisedb.com

Gregory Stark <stark@enterprisedb.com> writes:
> "Tom Lane" <tgl@sss.pgh.pa.us> writes:
>> The OID trick doesn't work very well either.

> expn "OID trick"?

See htup.h concerning where we stick OID into a tuple that has OID.
        regards, tom lane