On Thu, 2007-09-06 at 16:15 +0100, Heikki Linnakangas wrote:
> Tom Lane wrote:
> > "Heikki Linnakangas" <heikki@enterprisedb.com> writes:
> >> Imagine a page with just one tuple on it:
> >
> >> 1
> >
> >> After a bunch of updates, it looks like this
> >
> >> 1 -> 2 -> 3 -> 4 -> 5
> >
> >> 1 is the tuple the indexes point to, others are heap only.
> >
> > But if we were attempting prune at every update, at least some of the
> > later updates should have managed to prune. "2" should certainly be
> > gone at this point, unless there's lots of contention for the page,
> > in which case pruning at select won't make things better.
>
> Oh I see. Yeah, hopefully you don't end up with long chains too often.
> You don't need contention for it, though, a long-running transaction
> will cause it. Or a transaction that inserts a tuple and updates it
> multiple times in the same transaction.
Yes, the main point is that an UPDATE doesn't always allow you to prune.
If it did, that would be the right place. Since it doesn't the best
place to prune is surely the first time we see we *can* prune.
--
Simon Riggs
2ndQuadrant http://www.2ndQuadrant.com
