Re: Number of attributes in HeapTupleHeader - Mailing list pgsql-hackers

From Manfred Koizar
Subject Re: Number of attributes in HeapTupleHeader
Date
Msg-id 24hidugq6a7oo1rre97r5p6qu8u91mnede@4ax.com
Whole thread Raw
In response to Re: Number of attributes in HeapTupleHeader  ("Rod Taylor" <rbt@zort.ca>)
Responses Re: Number of attributes in HeapTupleHeader
List pgsql-hackers
On Mon, 6 May 2002 21:52:30 -0400, "Rod Taylor" <rbt@zort.ca> wrote:
>I think the real trick is keeping track of the difference between:
>
>begin;
>ALTER TABLE tab ADD COLUMN col1 int4 DEFAULT 4;
>commit;
>
>begin;
>ALTER TABLE tab ADD COLUMN col1;
>ALTER TABLE tab ALTER COLUMN col1 SET DEFAULT 4;
>commit;
>[...]
>begin;
>ALTER TABLE tab ADD COLUMN col1 DEFAULT 5;
>ALTER TABLE tab ALTER COLUMN col1 SET DEFAULT 4;
>commit;

This starts to get interesting.  Wouldn't it be cool, if PG could do
all these ALTER TABLE statements without touching any existing tuple?
This is possible; it needs a feature we could call MVMD (multi version
metadata).  How could that work?  I think of something like:

An ALTER TABLE statement makes a new copy of the metadata describing
the table, modifies the copy and gives it a unique (for this table)
version number.  It does not change or remove old metadata.

Every tuple knows the current metadata version as of the tuple's
creation.

Whenever a tuple is read, the correct version of the tuple descriptor
is associated to it.  All conversions to make the old tuple format
look like the current one are done on the fly.

When a tuple is updated, this clearly is handled like an insert, so
the tuple is converted to the most recent format.

The version number could be a small (1 byte) integer.  If we maintain
min and max valid version in the table metadata, we could even allow
the version to roll over to 0 after the highest possible value.  Max
version would be incremented by ALTER TABLE, min version could be
advanced by VACUUM.

The key point to make this work is whether we can keep the runtime
cost low.  I think there should be no problem regarding memory
footprint (just a few more tuple descriptors), but cannot (yet)
estimate the cpu overhead.

With MVMD nobody could call handling of pre ALTER TABLE tuples a hack
or a kludge.  There would be a well defined concept.

No, this concept is neither new nor is it mine.  I just like the idea,
and I hope I have described it correctly.

And no, I'm not whining that I think I need a feature and want you to
implement it for me.  I've got myself a shovel and a hoe and I'm ready
to dig, as soon as the hackers agree, where it makes sense.

Oh, just one wish:  please try to find friendly words, if you have to
tell me, that this is all bullshit :-)

ServusManfred


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Bad side-effect from making EXPLAIN return a select result
Next
From: "Marc G. Fournier"
Date:
Subject: Re: Path to PostgreSQL portabiliy