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 ---------------------------(end of broadcast)--------------------------- TIP 5: don't forget to increase your free space map settings
