Gokulakannan Somasundaram wrote:
On Nov 6, 2007 4:33 PM, Heikki Linnakangas <[EMAIL PROTECTED]> wrote:
Gokulakannan Somasundaram wrote:
Just one more thought on the same. This implementation also assumes
that there won't be any update chains across pages, which is the
current stage.
No, it doesn't assume that.
Say, if there is a tuple, which is visible to everyone, the Vacuum
process might have marked that block as visible. But the new update
which has happened, which is linked to the index tuple through the
head of the update chain might not be visible to everyone. How do you
think this design takes care of it?
Oh, I see. If it's a HOT update, the index-only-scan would still see the
right thing, because the old and the new row version have the same value
in the indexed columns.
Now if you also delete the heap-only tuple on the new page, that's
different from the page where the root tuple is, that's an interesting
situation. I suppose you'd have to clear the bit in the page holding the
root tuple instead of the page where the tuple itself is.
This is pretty academical, of course, because we don't know how exactly
the cross-page HOT update chains would work.
Heikki,
Is it planned as a optional feature? (I support the optional
feature model)
I'm not planning it. Clearly you are :-).
If you are planning it as a non-optional feature, you do realize that
there might be tables which don't need this index only scan and still
incur the extra overhead of maintaining the Visibility map.
Oh you were asking if I'm planning the visibility map as an optional
feature. I thought you meant if I'm planning the cross-page HOT update
chains.
I'm thinking the visibility map would always be there, assuming that
updating it is cheap enough. If we have the bit in the heap page header
as well, I believe it would be practically zero-cost.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
