Re: Visibility map thoughts - Mailing list pgsql-hackers

By the way, please have a look at how i have converted a index scan
into a index only scan in the thick index patch. Currently it doesn't
convert those queries which doesn't have where clause. I hope you
would be able refine it further.
For example, if there is a query like select count(1) from table. Then
we can scan through all the index pages and the visibility map to get
the count. Currently it goes for Full table scan. there should be
something like full index scan, which should take care of it. Thick
index  implementation will only go for index-only scans, if there is a
query with where clause (select count(1) from table where idxcol
between n1 and n2)

Thanks,
Gokul.

On Nov 6, 2007 8:24 PM, Heikki Linnakangas <heikki@enterprisedb.com> wrote:
> 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
>



-- 
Thanks,
Gokul.
CertoSQL Project,
Allied Solution Group.
(www.alliedgroups.com)