Thread: Questions about HeapTupleHeaderData

I try to understand why HeapTupleHeaderData structure has t_datum 
member. This is use only on few places and from my point of view this 
information should be stored in the HeapTupleData structure or split 
HeapTupleHeaderData it into two structures (DatumTupleHeaderData). The 
idea behind my question is that I need process different versions of 
HeapTupleHeaders for different page layouts and I try to discover how to 
deal with the union.

    Thanks Zdenek

Zdenek Kotala <Zdenek.Kotala@Sun.COM> writes:
> I try to understand why HeapTupleHeaderData structure has t_datum 
> member. This is use only on few places and from my point of view this 
> information should be stored in the HeapTupleData structure or split 
> HeapTupleHeaderData it into two structures (DatumTupleHeaderData).

Then (a) we'd have two struct definitions that have to stay in sync
and (b) we'd have to cast between HeapTupleHeader and DatumTupleHeader
pointer types in a bunch of places, adding notational messiness with
no advantage.
        regards, tom lane

Tom Lane napsal(a):
> Zdenek Kotala <Zdenek.Kotala@Sun.COM> writes:
>> I try to understand why HeapTupleHeaderData structure has t_datum 
>> member. This is use only on few places and from my point of view this 
>> information should be stored in the HeapTupleData structure or split 
>> HeapTupleHeaderData it into two structures (DatumTupleHeaderData).
> 
> Then (a) we'd have two struct definitions that have to stay in sync
> and (b) we'd have to cast between HeapTupleHeader and DatumTupleHeader
> pointer types in a bunch of places, adding notational messiness with
> no advantage.

If I understand correctly then for read path (select) tuple is always 
HeapTuple, because we need support select xmax ... And DatumTuple is 
used for write path (insert/update) and it is "converted" to HeapTuple 
in heap_insert/heap_update function.

Hmm I'm looking into executor and executor "converts" it when tuple is 
copied from buffer to work memory and processed.


However, Other kind of question is about space optimization.
From composite data type point of view it seems to me that we waste a 
lot of space. For example varlena is always 4 bytes and from infomask we 
need only HASVARWIDTH, HEAP_HASEXTERNAL and HASNULLS which could be 
placed into infomask2 and all transaction information should be in 
infomask. By my opinion we can save minimal 8 bytes there per composite 
type with reordering and of course minimal tuple could be smaller too.
OK any this changes bump page layout version which is not my goal now, 
but it could be idea for future development.
    Zdenek

Zdenek Kotala <Zdenek.Kotala@Sun.COM> writes:
> If I understand correctly then for read path (select) tuple is always 
> HeapTuple, because we need support select xmax ... And DatumTuple is 
> used for write path (insert/update) and it is "converted" to HeapTuple 
> in heap_insert/heap_update function.

No, DatumTuple is used for any free-standing composite-type Datum.
Thinking about it as "write path" and "read path" seems to me to
be missing the mark entirely.  In general most tuple-reading code
is supposed to work with either.
        regards, tom lane