Re: CTIDs invalidations and dropping columns.

On Tuesday 11 July 2006 17:27, Martijn van Oosterhout wrote:
> On Tue, Jul 11, 2006 at 01:50:40AM +0300, Tzahi Fadida wrote:
> > As i understand rowids, i.e ctids, are supposed to allow for fast access
> > to the tables. I don't see the rational, for example, when casting some
> > attributes, to blank the ctid. So it is not exactly the same, but it
> > still came from the same tuple. What will happen if for read only SPI
> > queries it will not be blank?
>
> Did you read the email Tom sent?

yes, if it is potentially broken, i think i should better use the attribute 
CTID even if there would be a performance drop.

>
> I worked out the exact issue with your example btw. It's because of the
> DROP COLUMN. After dropping the column the tuples on disk have 3
> columns and you only asked for 2, so an extra step has to be taken.
> This extra step copies the two values, creating a new tuple, which has
> no CTID.

10x. i c what you mean.

>
> If you're tying yourself this tightly to the backend, maybe you should
> just use index_beginscan/heap_beginscan/etc which return actual tuples.

I am considering it, however, it will also be accompanied with areas that 
SPI/engine previously handled that i will have to manage myself. 
I'll have to experiment a bit and see what is more important the Reuse of spi/ 
or the performance gains of heap_beginscan...

>
> Have a nice day,

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