Simon Riggs wrote:
> On Sun, 2010-01-31 at 20:48 +0100, Stefan Kaltenbrunner wrote:
>> Simon Riggs wrote:
>>> On Sun, 2010-01-31 at 14:07 -0500, Tom Lane wrote:
>>>
>>>>> The commit is a one line change, with parameter to control it, discussed
>>>>> by Heikki and myself in December 2008. I stand by the accuracy of the
>>>>> change; the parameter is really to ensure we can test during beta.
>>>> Well, I was waiting to see if anyone else had an opinion, but: my
>>>> opinion is that a GUC is not appropriate here. Either test it yourself
>>>> enough to be sure it's a win, or don't put it in.
>>> I will remove the parameter then, keeping the augmentation. That OK?
>> Well how much is the actual hit with this on the master for different
>> workloads do we have realistic numbers on that? Also how much of an
>> actual win is it in the other direction - as in under what circumstances
>> and workloads does it help in avoiding superflous cancelations on the
>> standby?
>
> At the moment a btree delete record will cancel every request
> 1. no matter how long they have been running
> 2. no matter if they haven't accessed the index being cleaned (they
> might later, is the thinking...)
>
> This change improves case (1) in that it will only remove queries that
> are older than the oldest snapshot on the primary, should
> max_standby_delay be exceeded. Case (2) would have been improved by my
> other proposed patch should max_standby_delay be exceeded.
>
> The cost of improving case (1) is that we do the equivalent of taking a
> snapshot of the procarray while holding locks on the btree block being
> cleaned. That will increase index contention somewhat in applications
> that do btree deletes, i.e. non-hot index updates or deletes.
hmm makes sense from the HS side - but I think to make a case for a GUC
it would help a lot to see actual numbers(as in benchmarks) showing how
much of a hit it is to the master.
Stefan
