Tom Lane napsal(a):
Zdenek Kotala <[EMAIL PROTECTED]> 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 prevent that.
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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
