CTIDs invalidations and dropping columns. - Mailing list pgsql-hackers

From Tzahi Fadida
Subject CTIDs invalidations and dropping columns.
Date
Msg-id 200607102347.24325.Tzahi.ML@gmail.com
Whole thread Raw
Responses Re: CTIDs invalidations and dropping columns.
List 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


pgsql-hackers by date:

Previous
From: Josh Berkus
Date:
Subject: Re: Removing AddDepends; should I bother with a project?
Next
From: Tom Lane
Date:
Subject: Re: A couple thoughts about btree fillfactor