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@svana.org> http://svana.org/kleptog/ > From each according to his ability. To each according to his ability to > litigate.
signature.asc
Description: Digital signature
