Re: PG_PAGE_LAYOUT_VERSION 5 - time for change

From: Zdenek Kotala <Zdenek(dot)Kotala(at)Sun(dot)COM>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: PG_PAGE_LAYOUT_VERSION 5 - time for change
Date: 2008-10-31 12:14:37
Message-ID: 490AF6AD.8060300@sun.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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 */
>
>> 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Sam Mason 2008-10-31 12:19:54 Re: array_agg and array_accum (patch)
Previous Message Fujii Masao 2008-10-31 11:36:39 Synchronous replication patch v1