Tom Lane napsal(a):
> Zdenek Kotala <Zdenek(dot)Kotala(at)Sun(dot)COM> writes:
>> 1) HeapTupleHeader modification
>> typedef struct HeapTupleFields
>> TransactionId t_xmin; /* inserting xact ID */
>> TransactionId t_xmax; /* deleting or locking xact ID */
>> 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
> And you didn't explain exactly what it buys, anyway. Not space savings
> in the Datum form; alignment issues will prevent that.
OK. The idea is to consolidate structures. Idea is to have basic structure for data:
typedef struct 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
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
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.
In response to
pgsql-hackers by date
|Next:||From: Sam Mason||Date: 2008-10-31 12:19:54|
|Subject: Re: array_agg and array_accum (patch)|
|Previous:||From: Fujii Masao||Date: 2008-10-31 11:36:39|
|Subject: Synchronous replication patch v1|