Re: CTIDs invalidations and dropping columns.
От | Martijn van Oosterhout |
---|---|
Тема | Re: CTIDs invalidations and dropping columns. |
Дата | |
Msg-id | 20060711142718.GB6500@svana.org обсуждение исходный текст |
Ответ на | Re: CTIDs invalidations and dropping columns. (Tzahi Fadida <Tzahi.ML@gmail.com>) |
Ответы |
Re: CTIDs invalidations and dropping columns.
|
Список | pgsql-hackers |
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? 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. If you're tying yourself this tightly to the backend, maybe you should just use index_beginscan/heap_beginscan/etc which return actual tuples. 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.
В списке pgsql-hackers по дате отправления: