Re: CTIDs invalidations and dropping columns.

On Mon, Jul 10, 2006 at 11:47:23PM +0300, Tzahi Fadida wrote:
> 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...)?

You're talking about "invalidation" as if it's something someone
deliberately does. That's incorrect. The t_ctid field is filled in if
and only if the tuple is exactly the on disk tuple. Otherwise it's a
new tuple, which by definition does not have a ctid (it doesn't exist
on disk).

> 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.

This doesn't make any sense. What is invalidated? Is it blank or what?
I think you're going to have to provide some example code.

What do you mean by "invalidation" 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.

You've measured this performance difference?

Have a nice day,
--
Martijn van Oosterhout <kleptog(at)svana(dot)org> http://svana.org/kleptog/
> From each according to his ability. To each according to his ability to litigate.