pg.ddx.io  pgsql-performance@postgresql.org mailing list archive  

help / color / mirror / Atom feed
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andres Freund <andres@2ndquadrant.com>
Cc: Josh Berkus <josh@agliodbs.com>
Cc: Jeff Janes <jeff.janes@gmail.com>
Cc: pgsql-performance@postgresql.org <pgsql-performance@postgresql.org>
Cc: Bart³omiej Romañski <br@sentia.pl>
Subject: Re: Planner performance extremely affected by an hanging transaction (20-30 times)?
Date: Tue, 25 Feb 2014 11:06:51 -0500
Message-ID: <32089.1393344411@sss.pgh.pa.us> (raw)
In-Reply-To: <11927.1384199294@sss.pgh.pa.us>
References: <5815.1380018947@sss.pgh.pa.us>
	<e8795f5e292a0bd1a4d8ebbcb54e4a98.squirrel@shrek.krogh.cc>
	<WM!41fcd3fa079d542735fe69d3254859689c1085f7c897fa6e9a9b828ad9d2c80ba7b6b2c4c67c942a6115262993147370!@asav-1.01.com>
	<5241CF2A.2070309@agliodbs.com>
	<CAMkU=1ys-fB2Nczt=LT1pVHzK3Jv4Jb-67N29Gzyx3nraweoZQ@mail.gmail.com>
	<20130925175312.GB5578@awork2.anarazel.de>
	<CAMkU=1yy-YEQVvqj2xJitT1EFkyuFk7uTV_hrOMGyGMxpU=N+Q@mail.gmail.com>
	<20130925184330.GC5578@awork2.anarazel.de>
	<WM!93b9a5691f0628ebed5547d1ebe916326a0f388cbdc28742bef1b0c7862375a07b801f17c707cbdf6a3104b7920696af!@asav-1.01.com>
	<5245F11E.20804@agliodbs.com>
	<20130927211439.GB7260@awork2.anarazel.de>
	<11927.1384199294@sss.pgh.pa.us>
List-Unsubscribe:  <mailto:majordomo@postgresql.org?body=unsub%20pgsql-performance>

I wrote:
> Andres Freund <andres@2ndquadrant.com> writes:
>> Also, this really isn't going to fix the issue discussed here - this was
>> just about the additional ProcArrayLock contention. I don't think it
>> would change anything dramatical in your case.

> All of these proposals are pretty scary for back-patching purposes,
> anyway.  I think what we should consider doing is just changing
> get_actual_variable_range() to use a cheaper snapshot type, as in
> the attached patch (which is for 9.3 but applies to 9.2 with slight
> offset).  On my machine, this seems to make the pathological behavior
> in BR's test case go away just fine.  I'd be interested to hear what
> it does in the real-world scenarios being complained of.

Well, it's three months later, and none of the people who were complaining
so vociferously in this thread seem to have bothered to test the proposed
solution.

However, over at
http://www.postgresql.org/message-id/CAFj8pRDHyAK_2JHSVKZ5YQNGQmFGVcJKcpBXhFaS=vSSCH-vNw@mail.gmail....
Pavel did test it and reported that it successfully alleviates his
real-world problem.  So I'm now inclined to commit this.  Objections?

			regards, tom lane


-- 
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance



view thread (25+ messages)  latest in thread

Message-ID: <32089.1393344411@sss.pgh.pa.us>
Permalink:  ../32089.1393344411@sss.pgh.pa.us/
Also on:    postgresql.org/message-id/32089.1393344411@sss.pgh.pa.us

 · 

reply
Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-performance@postgresql.org
  Cc: tgl@sss.pgh.pa.us, andres@2ndquadrant.com, josh@agliodbs.com, jeff.janes@gmail.com, br@sentia.pl
  Subject: Re: Planner performance extremely affected by an hanging transaction (20-30 times)?
  In-Reply-To: <32089.1393344411@sss.pgh.pa.us>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox