Re: [HACKERS] Tuple alignment
Gregory Stark <[EMAIL PROTECTED]> writes: > "Tom Lane" <[EMAIL PROTECTED]> 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 ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Tuple alignment
"Tom Lane" <[EMAIL PROTECTED]> writes: > Heikki Linnakangas <[EMAIL PROTECTED]> 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 ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Tuple alignment
Heikki Linnakangas <[EMAIL PROTECTED]> 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 ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
[HACKERS] 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 ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
