Re: PG_PAGE_LAYOUT_VERSION 5 - time for change

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

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. And you didn't explain exactly
what it buys, anyway. Not space savings in the Datum form; alignment
issues will prevent that.

> 2) Add page type (e.g. btree) and subtype (e.g. metapage) flag into page header.
> I think It will be useful when we will use share buffer for clog.

I think this is a pretty bad idea, because it'll eat space on every page
for data that is only useful to indexes. I don't believe that clog will
find it interesting either. To share buffers with clog will require
a change in buffer lookup tags, not buffer contents.

> 3) TOAST modification
> a) TOAST table per attribute
> b) replace chunk id with offset+variable chunk size
> c) add column identification into first chunk

I don't like 3a any more than Greg does. 3b sounds good until you
reflect that a genuinely variable chunk size would preclude random
access to sub-ranges of a toast value. A column ID might be worth
adding for robustness purposes, though reducing the toast chunk payload
size to make that possible will cause you fits for in-place upgrade.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Gregory Stark 2008-10-30 23:33:27 Re: PG_PAGE_LAYOUT_VERSION 5 - time for change
Previous Message David Rowley 2008-10-30 23:04:42 Re: TABLE command