From: | Manfred Koizar <mkoi-pg(at)aon(dot)at> |
---|---|
To: | "Rod Taylor" <rbt(at)zort(dot)ca> |
Cc: | "Hiroshi Inoue" <Inoue(at)tpf(dot)co(dot)jp>, "Neil Conway" <nconway(at)klamath(dot)dyndns(dot)org>, <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Number of attributes in HeapTupleHeader |
Date: | 2002-05-08 16:19:18 |
Message-ID: | 24hidugq6a7oo1rre97r5p6qu8u91mnede@4ax.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, 6 May 2002 21:52:30 -0400, "Rod Taylor" <rbt(at)zort(dot)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 :-)
Servus
Manfred
From | Date | Subject | |
---|---|---|---|
Next Message | mlw | 2002-05-08 16:29:07 | Re: Path to PostgreSQL portabiliy |
Previous Message | Thomas Lockhart | 2002-05-08 16:10:44 | Re: Path to PostgreSQL portabiliy |