Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1VJNts-0001QG-Qs for pgsql-performance@arkaria.postgresql.org; Tue, 10 Sep 2013 13:22:37 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.80) (envelope-from ) id 1VJNtr-000760-Qa for pgsql-performance@arkaria.postgresql.org; Tue, 10 Sep 2013 13:22:35 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1VJNtq-00075t-Np for pgsql-performance@postgresql.org; Tue, 10 Sep 2013 13:22:34 +0000 Received: from mail.anarazel.de ([217.115.131.40]) by magus.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1VJNti-0006Gd-Ta for pgsql-performance@postgresql.org; Tue, 10 Sep 2013 13:22:34 +0000 Received: from intern.anarazel.de (unknown [82.113.99.216]) (Authenticated sender: andres@anarazel.de) by mail.anarazel.de (Postfix) with ESMTPSA id 9F5094E8002; Tue, 10 Sep 2013 15:22:23 +0200 (CEST) Date: Tue, 10 Sep 2013 15:21:33 +0200 From: Andres Freund To: Andrew Dunstan Cc: Jeff Janes , Josh Berkus , Amit Kapila , "pgsql-performance@postgresql.org" Subject: Re: Performance bug in prepared statement binding in 9.2? Message-ID: <20130910132133.GJ1024477@alap2.anarazel.de> References: <51A699E6.3000008@agliodbs.com> <51A79512.4020200@agliodbs.com> <51FAA1B8.6040809@agliodbs.com> <522E69F1.8070203@dunslane.net> <20130910122036.GF1024477@alap2.anarazel.de> <522F146D.2070908@dunslane.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <522F146D.2070908@dunslane.net> X-Pg-Spam-Score: -2.6 (--) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-performance Precedence: bulk Sender: pgsql-performance-owner@postgresql.org 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