Re: Number of attributes in HeapTupleHeader
| От | Manfred Koizar |
|---|---|
| Тема | Re: Number of attributes in HeapTupleHeader |
| Дата | |
| Msg-id | 24hidugq6a7oo1rre97r5p6qu8u91mnede@4ax.com обсуждение исходный текст |
| Ответ на | Re: Number of attributes in HeapTupleHeader ("Rod Taylor" <rbt@zort.ca>) |
| Ответы |
Re: Number of attributes in HeapTupleHeader
|
| Список | 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 по дате отправления: