From: Andres Freund <andres@2ndquadrant.com>
To: Andrew Dunstan <andrew@dunslane.net>
Cc: Jeff Janes <jeff.janes@gmail.com>
Cc: Josh Berkus <josh@agliodbs.com>
Cc: Amit Kapila <amit.kapila@huawei.com>
Cc: pgsql-performance@postgresql.org <pgsql-performance@postgresql.org>
Subject: Re: Performance bug in prepared statement binding in 9.2?
Date: Tue, 10 Sep 2013 15:21:33 +0200
Message-ID: <20130910132133.GJ1024477@alap2.anarazel.de> (raw)
In-Reply-To: <522F146D.2070908@dunslane.net>
References: <51A699E6.3000008@agliodbs.com>
<WM!f3d412a8ff9fb2a52f4cfd0f48c225b6122ba5bf1e1523173b5dbc63db143b9cab09ac3f5518a12a19d2507538472d98!@asav-1.01.com>
<51A79512.4020200@agliodbs.com>
<WM!c84cb8479a8b2ec21d1061c951095da00bc52608e9822124f1438b9de432ec7ebedaf25085801b67d581eed6d368c344!@asav-2.01.com>
<51FAA1B8.6040809@agliodbs.com>
<CAMkU=1wn3npjTjEkC8rYMgmoKXYoAgfxosT_Q3v_=wTfriPKdA@mail.gmail.com>
<522E69F1.8070203@dunslane.net>
<20130910122036.GF1024477@alap2.anarazel.de>
<522F146D.2070908@dunslane.net>
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-performance>
On 2013-09-10 08:45:33 -0400, Andrew Dunstan wrote:
>
> On 09/10/2013 08:20 AM, Andres Freund wrote:
>
> >A backtrace for this would be useful. Alternatively you could recompile
> >postgres using -fno-omit-frame-pointer in CFLAGS and use perf record -g.
>
> It's using a custom build, so this should be doable.
Great.
> >Any chance you have older prepared xacts, older sessions or something
> >like that around? I'd expect heap_prune* to be present in workloads that
> >spend significant time in heap_hot_search_buffer...
>
>
> Not sure about prepared transactions. There are certainly probably old
> prepared statements around, and long running transactions alongside this
> one.
Ok, long running transactions will do the trick. I quicky checked and
doing an index lookup for min/max histogram lookups was added *after*
8.4 which would explain why you're not seing the issue there
(c.f. 40608e7f949fb7e4025c0ddd5be01939adc79eec).
It getting slower and slower during a testrun would be explained by the
additional tuple versions amassing which cannot be marked dead because
of older transactions around. I guess those are also part of the test?
If I interpret things correctly you're using serializable? I guess there
is no chance to use repeatable read instead?
Greetings,
Andres Freund
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
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: andres@2ndquadrant.com, andrew@dunslane.net, jeff.janes@gmail.com, josh@agliodbs.com, amit.kapila@huawei.com
Subject: Re: Performance bug in prepared statement binding in 9.2?
In-Reply-To: <20130910132133.GJ1024477@alap2.anarazel.de>
* 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