Re: planner/optimizer question
От | Manfred Koizar |
---|---|
Тема | Re: planner/optimizer question |
Дата | |
Msg-id | toe590tgu39ilahg3p1os2mjlgf4iss582@email.aon.at обсуждение исходный текст |
Ответ на | Re: planner/optimizer question (Jochem van Dieten <jochemd@oli.tudelft.nl>) |
Ответы |
Re: planner/optimizer question
|
Список | pgsql-performance |
On Fri, 30 Apr 2004 19:46:24 +0200, Jochem van Dieten <jochemd@oli.tudelft.nl> wrote: >> While the storage overhead could be reduced to 1 bit (not a joke) > >You mean adding an isLossy bit and only where it is set the head >tuple has to be checked for visibility, if it is not set the head >tuple does not have to be checked? Yes, something like this. Actually I imagined it the other way round: a visible-to-all flag similar to the existing dead-to-all flag (search for LP_DELETE and ItemIdDeleted in nbtree.c). >> we'd >> still have the I/O overhead of locating and updating index tuples for >> every heap tuple deleted/updated. > >Would there be additional I/O for the additional bit in the index >tuple (I am unable to find the layout of index tuple headers in >the docs)? Yes, the visible-to-all flag would be set as a by-product of an index scan, if the heap tuple is found to be visible to all active transactions. This update is non-critical and, I think, not very expensive. Deleting (and hence updating) a tuple is more critical, regarding both consistency and performance. We'd have to locate all index entries pointing to the heap tuple and set their visible-to-all flags to false.
В списке pgsql-performance по дате отправления: