Re: PG_PAGE_LAYOUT_VERSION 5 - time for change

Tom Lane napsal(a):
> Zdenek Kotala <Zdenek.Kotala@Sun.COM> writes:
>> 1) HeapTupleHeader modification
> 
>> typedef struct HeapTupleFields
>> {
>>     TransactionId t_xmin;           /* inserting xact ID */
>>          TransactionId t_xmax;           /* deleting or locking xact ID */
> 
>>          union
>>          {
>>                  CommandId       t_cid;
>>                  TransactionId   t_xvac;   /* VACUUM FULL xact ID */
>>          }                       t_field3;
>>      uint16          t_infomask;
>> } HeapTupleFields;
> 
> This is unworkable (hint: the compiler will decide sizeof the struct
> must be a multiple of 4).  I am also frightened to death of the proposal
> to swap various bits around between infomask and infomask2 --- that is
> *guaranteed* to break code silently. 

Uh? If flags shuffle breaks code that is not good for in-place upgrade anyway. 
Do you mean something specific? I already transform all access to FLAGS into 
functions.

> And you didn't explain exactly what it buys, anyway.  Not space savings > in the Datum form; alignment issues will
preventthat.
 

OK. The idea is to consolidate structures. Idea is to have basic structure for data:

typedef struct DataHeaderData        uint16          t_infomask2;        uint8           t_hoff;        bits8
t_bits[1];
} DataHeaderData

which is correspond with minimal tuple an it is also useful for index tuple.
If I understand correctly then other  (transaction) information is not useful in 
executor (exclude when they are explicitly mentioned in select)
I'm not sure but I think we can store composite types without typid and typmod 
and it save some bytes. After that we can have structure e.g. 
VisibilityTupleHeader, DatumTupleHeader, IndexTupleHeader. And data on disk will 
be stored:

VisibilityTupleHeaderData|DataHeaderData|Data....
IndexTupleHeader|DataHeaderData|Data....

It has problem with aligment but visibility or index data could be place into 
line item pointer (IIRC somebody suggested it for vacuum improvement). And 
HeapTupleData structure should be extended:

t_data - pointer on DataHeaderData
t_type - type of data header
t_header - pointer to Visibility/Datum/Index header

The main idea behind is to have stable,general and minimalistic DataHeader 
structure.

It is just idea without deep examination. It seems to me as a good idea how to 
save a memory footprint as well, but maybe I'm wrong.
    Zdenek