Re: HOT patch - version 15 - Mailing list pgsql-patches

From Simon Riggs
Subject Re: HOT patch - version 15
Date
Msg-id 1189107302.4175.401.camel@ebony.site
Whole thread Raw
In response to Re: HOT patch - version 15  ("Heikki Linnakangas" <heikki@enterprisedb.com>)
Responses Re: HOT patch - version 15  (Bruce Momjian <bruce@momjian.us>)
List pgsql-patches
On Thu, 2007-09-06 at 19:05 +0100, Heikki Linnakangas wrote:

> Pruning is expensive, you need to scan all tuples on
> the page and write WAL record. And defragment the page if you consider
> that part of pruning. You don't want to do it too aggressively.

OK, so my understanding or the meaning of the word has changed since we
decided that initial behaviour. So yes, not too aggressively.

Elsewhere on this thread, I said:

On Thu, 2007-09-06 at 18:05 +0100, Simon Riggs wrote:

> We could begin pruning only when the chain is N long. Currently N=2, but
> we could set N=3+ easily enough. There's no code yet to actually count
> that, but we can do that easily as we do each lookup. We should also be
> able to remember the visibility result for each tuple in the chain to
> decide whether pruning will be effective or not.
>
> I would say that if the buffer is already dirty and the chain is
> prunable, we should prune it at the first possible chance.

If we defer pruning until the page is full, worst case we may could end
up with a chain ~240 tuples long, which might need to be scanned
repeatedly. That won't happen often, but it would be better to prune
whenever we hit one of these conditions
- when the block is full
- when we reach the 16th tuple in a chain

--
  Simon Riggs
  2ndQuadrant  http://www.2ndQuadrant.com


pgsql-patches by date:

Previous
From: Tom Lane
Date:
Subject: Re: HOT patch - version 15
Next
From: Tom Lane
Date:
Subject: Re: HOT patch - version 15