Gokulakannan Somasundaram wrote:
> On Nov 6, 2007 4:33 PM, Heikki Linnakangas <heikki@enterprisedb.com> 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
