Re: Re: [COMMITTERS] pgsql: Augment WAL records for btree delete with GetOldestXmin() to

From: Simon Riggs <simon(at)2ndQuadrant(dot)com>
To: Stefan Kaltenbrunner <stefan(at)kaltenbrunner(dot)cc>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Re: [COMMITTERS] pgsql: Augment WAL records for btree delete with GetOldestXmin() to
Date: 2010-01-31 20:13:55
Message-ID: 1264968835.13782.8546.camel@ebony
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-committers pgsql-hackers

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.

Greg Stark's comments have been that he wants to see max_standby_delay =
-1 put back, which would effecively prevent both (1) and (2) from
occurring. I am working on that now.

--
Simon Riggs www.2ndQuadrant.com

In response to

Responses

Browse pgsql-committers by date

  From Date Subject
Next Message User Richtej 2010-01-31 20:26:50 pgsphere - pgsphere: # Fixes some precission problems with small
Previous Message Stefan Kaltenbrunner 2010-01-31 19:48:25 Re: Re: [COMMITTERS] pgsql: Augment WAL records for btree delete with GetOldestXmin() to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2010-01-31 20:14:19 Re: Hot Standby and VACUUM FULL
Previous Message Simon Riggs 2010-01-31 20:06:44 Re: Hot Standby and VACUUM FULL