Re: HOT patch - version 15

Gregory Stark wrote:
> "Bruce Momjian" <bruce(at)momjian(dot)us> writes:
>
> > Looking at the patch I see:
> >
> > + /*
> > + * Mark the page as clear of prunable tuples. If we find a tuple which
> > + * may become prunable, we shall set the hint again.
> > + */
> > + PageClearPrunable(page);
> >
> > I like the idea of the page hint bit, but my question is if there is a
> > long-running transaction, isn't each SELECT going to try to defragment a
> > page over and over again because there is still something prunable on
> > the page?
>
> Well it'll try to prune the chains over and over again. If it doesn't find
> anything it won't defragment, but yes.
>
> I think we could tackle that by storing on the page the oldest xmax which
> would allow us to prune a tuple. Then you could compare RecentGlobalXmin
> against that and not bother looking at any other chains if it hasn't been
> passed yet.

Yea, that might work if we have space on the page.

> It would be hard to do that with single-chain pruning though, once you the
> limiting tuple you would then wouldn't know what the next limiting xmax is
> until the next time you do a full-page prune. Still that gets us down to at
> most two full-page prunes per update instead of a potentially unbounded number
> of prunes.
>
> This seems like a further optimization to think about after we have a place to
> trigger the pruning where it'll do the most good.

I was thinking if we could only try defragementing when we are doing an
INSERT or UPDATE, then the defragment would either free enough space so
we could stay on the page or the new row would go on another page and we
would probably not return to that page again anytime soon.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://www.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +