Re: [HACKERS] Re: pgsql: Avoid extra locks in GetSnapshotData if old_snapshot_threshold < - Mailing list pgsql-committers

From Andres Freund
Subject Re: [HACKERS] Re: pgsql: Avoid extra locks in GetSnapshotData if old_snapshot_threshold <
Date
Msg-id 20160507221105.rjjtdir65obkjn2g@alap3.anarazel.de
Whole thread Raw
In response to Re: [HACKERS] Re: pgsql: Avoid extra locks in GetSnapshotData if old_snapshot_threshold <  (Kevin Grittner <kgrittn@gmail.com>)
List pgsql-committers
On 2016-05-06 20:28:27 -0500, Kevin Grittner wrote:
> On Fri, May 6, 2016 at 7:48 PM, Andres Freund <andres@anarazel.de> wrote:
> > On 2016-05-06 19:43:24 -0500, Kevin Grittner wrote:
> >> It's disappointing that I am not getting more consistent numbers,
> >> but NUMA can be hard to manage that way.
> >
> > FWIW, in my experience, unless you disable autovacuum (or rather
> > auto-analyze), the effects from non-predicable analyze runs with
> > long-running snapshots are worse.  I mean the numa effects suck, but in
> > r/w workload effects of analyze are often much worse.
>
> Hm.  But the benefits of the patch are not there if autovacuum is
> off.  I'm gonna need to ponder the best way to test given all that.

It's sufficient to set the threshhold for analyze very high, as vacuum
itself doesn't have that problem. I basically just set
autovacuum_analyze_threshold to INT_MAX , that alleviates the problem
for normal runs.

Andres


pgsql-committers by date:

Previous
From: Tom Lane
Date:
Subject: pgsql: Release notes for 9.5.3, 9.4.8, 9.3.13, 9.2.17, 9.1.22.
Next
From: Tom Lane
Date:
Subject: Re: pgsql: Disable BLOB test in pg_dump TAP tests