Re: Visibility map thoughts

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.

Heikki,
Is it planned as a optional feature? (I support the optional
feature model)

Thanks,
Gokul.

On Nov 6, 2007 12:20 PM, Gregory Stark <stark(at)enterprisedb(dot)com> wrote:
> "Heikki Linnakangas" <heikki(at)enterprisedb(dot)com> writes:
>
> > One problem is that you have to atomically update the visibility map when
> > you update the heap. That means that you have to lock the visibility map
> > page and the heap page at the same time. If the visibility map is in the
> > heap, you need to take care that you don't deadlock.
>
> Well that's still a problem if it's in another filenode.
>
> On the other hand if you allocate a whole byte to every page you could set it
> atomically and not have to lock the page. Effectively having the lock on the
> original page protect the info byte. Whereas setting a single bit requires
> protecting against someone setting one of the other bits corresponding to
> another page entirely.
>
> >>> - We don't need to clear the bit on HOT updates, because by definition none
> >>> of the indexed columns changed.
> >>
> >> Huh? I don't think I believe that, and I definitely don't believe your
> >> argument for it.
> >
> > HOT-updating a row doesn't change what an index-only scan would see. An
> > index-only scan only needs columns that are in the index, and since it's a HOT
> > update, none of those columns have changed, so it doesn't matter which tuple
> > we're returning them from.
> >
> > Pages that have HOT updated tuples, but haven't otherwise been modified since
> > last vacuum are also not interesting for VACUUM, because a prune will do the
> > job of getting rid of dead HOT-updated tuples just as well.
> >
> > Am I missing something?
>
> I think the point is that for index-only scans you really just want to know
> the visibility of the whole chain. The whole chain is either known-visible or
> not. A HOT update doesn't change that, it just changes which version along the
> chain is visible and the values of the non-indexed columns in that version.
>
> Some thought has to be given to the transition stages when you create or drop
> an index but I don't see a problem there. If you have a "broken" hot chain it
> doesn't change the visibility rules for anyone who does use an old index (and
> nobody who could see the broken end of the chain should be using the new index
> anyways).
>
> The problem with this is that it's different from what a DSM would need. We
> could skip vacuuming such HOT updated dead tuples, assuming a page prune will
> get it the next time we access the page I suppose. Or we could use a separate
> bit for more aggressive vacuum information.
>
>
> --
> Gregory Stark
> EnterpriseDB http://www.enterprisedb.com
> Ask me about EnterpriseDB's Slony Replication support!
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 3: Have you checked our extensive FAQ?
>
> http://www.postgresql.org/docs/faq
>

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