Skip site navigation (1) Skip section navigation (2)

Re: Changing data types

From: Alex Pilosov <alex(at)pilosoft(dot)com>
To: Rod Taylor <rod(dot)taylor(at)inquent(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Changing data types
Date: 2001-09-25 02:31:36
Message-ID: Pine.BSO.4.10.10109242227340.28103-100000@spider.pilosoft.com (view raw or flat)
Thread:
Lists: pgadmin-hackerspgsql-hackers
On Mon, 24 Sep 2001, Rod Taylor wrote:

> Out of curiosity how was option a) implemented?  I could envision
> supporting multiple versions of a tuple style to be found within a
> table (each described in pg_attribute).  Gradually these would be
> upgraded through normal use.
Check the archives (look for "DROP COLUMN" and "Hiroshi Inoue", author of
original patch).

> One would expect that keeping multiple versions of a tuple structure
> inside a single table to be slower than normal for selects, but I
> don't think it would require marking the rows themselves -- just base
> it on the max and min transactions in the table at that time.  Vacuum
> would have to push the issue (5k tuples at a time?) of upgrading some
> of the tuples each time it's run in order to enfore that they were all
> gone before XID wrap.  Background vacuum is ideal for that (if
> implemented).  Drop all constraints, indexes and the name (change to
> $1 or something) of the column immediatly.  Vacuum can determine when
> XID Min in a table is > XID Max of another version and drop the
> information from pg_attribute.
I think it was done by setting attribute_id to negative, essentially
hiding it from most code, instead of having two tuple versions, but I
really am not very familiar. Check archives :)

> Obviously affected:
> - pg_attribute, and anything dealing with it (add XID Max, XID Min
> wraps for known ranges)
> - storage machanism.  On read of a tuple attempt to make it fit latest
> version (XID Max is NULL) by ignoring select fields.
> 
> I'll have to leave it up to the pros as to whether it can be done,
> should be done, and what else it'll affect.
> 
> I suppose this was option a) that was removed due to it's kludgyness
> :)



In response to

pgsql-hackers by date

Next:From: Tatsuo IshiiDate: 2001-09-25 02:42:28
Subject: Proposal: new GUC paramter
Previous:From: Rod TaylorDate: 2001-09-25 02:22:09
Subject: Re: Changing data types

pgadmin-hackers by date

Next:From: Jean-Michel POUREDate: 2001-09-25 19:59:16
Subject: Pseudo table modification
Previous:From: Rod TaylorDate: 2001-09-25 02:22:09
Subject: Re: Changing data types

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group