CTIDs invalidations and dropping columns.

From: Tzahi Fadida <Tzahi(dot)ML(at)gmail(dot)com>
To: pgsql-hackers(at)postgresql(dot)org
Subject: CTIDs invalidations and dropping columns.
Date: 2006-07-10 20:47:23
Message-ID: 200607102347.24325.Tzahi.ML@gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,
First, i use CTIDs to immensely speed up my function which is inherently slow
because of the problem itself.

I have a question about CTID invalidation when you open a read only cursor
using SPI. Why does it at all happens? Why is it so important to invalidate a
ctid of a read only query (for example when using indices, casting,etc...)?

Specifically, i encountered something unexpected. i created a table:
(a2 int4, a0 int4) then i did alter table add column a5 int4, then update set
a5=a0, update set a0=a0+1, alter table drop column a0.

Now that i run a simple select * from SPI cursor query on this table and
look at the t_data->t_ctid i see that the ctids are invalidated for some
unknown reason?
previously before the alter table it was ok.

I am using 8.1.4, can you tell me if it is a bug/feature/don't care about
ctids in spi... reason.

Is it such a difficult thing to return ctids if the query is read only. where
is it invalidated anyway?
I highly prefer not to use CTID as an attribute since it is going to greatly
lower the performance since it is sitting on a bottleneck.

--
Regards,
        Tzahi.
--
Tzahi Fadida
Blog: http://tzahi.blogsite.org | Home Site: http://tzahi.webhop.info
WARNING TO SPAMMERS:  see at
http://members.lycos.co.uk/my2nis/spamwarning.html

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message David Fetter 2006-07-10 20:51:32 Re: Removing AddDepends; should I bother with a project?
Previous Message Bruce Momjian 2006-07-10 20:43:14 Re: More nuclear options