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 <[EMAIL PROTECTED]> wrote:
> "Heikki Linnakangas" <[EMAIL PROTECTED]> 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)
---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
