Received: from localhost (unknown [200.46.208.211]) by mail.postgresql.org (Postfix) with ESMTP id 77647633B1E; Mon, 9 Mar 2009 18:32:22 -0300 (ADT) Received: from mail.postgresql.org ([200.46.204.86]) by localhost (mx1.hub.org [200.46.208.211]) (amavisd-maia, port 10024) with ESMTP id 14110-02; Mon, 9 Mar 2009 18:32:16 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from tremor.opencloud.co.nz (tremor.opencloud.co.nz [131.203.101.230]) by mail.postgresql.org (Postfix) with ESMTP id 5BB576339C8; Mon, 9 Mar 2009 18:32:18 -0300 (ADT) Received: from 219-89-241-75.adsl.xtra.co.nz ([219.89.241.75] helo=[192.168.1.3]) by tremor.opencloud.co.nz with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1Lgn4n-0005wT-Nr; Tue, 10 Mar 2009 10:31:57 +1300 Message-ID: <49B58ABE.7070105@opencloud.com> Date: Tue, 10 Mar 2009 10:31:42 +1300 From: Oliver Jowett User-Agent: Thunderbird 2.0.0.19 (X11/20090105) MIME-Version: 1.0 To: Dave Cramer CC: Tom Lane , Guillaume Smet , Guillaume Cottenceau , Mario Splivalo , pgsql-performance@postgresql.org, pgsql-jdbc@postgresql.org, scott@richrelevance.com Subject: Re: [PERFORM] Query much slower when run from postgres function References: <49B51B60.6030600@megafon.hr> <27649.1236616294@sss.pgh.pa.us> <87fxhmmygj.fsf@meuh.mnc.lan> <1d4e0c10903091004m758d7ea2s91e33631be81215a@mail.gmail.com> <5165.1236618994@sss.pgh.pa.us> <491f66a50903091256n7fe4a3f6i93267d0d53b983cb@mail.gmail.com> In-Reply-To: <491f66a50903091256n7fe4a3f6i93267d0d53b983cb@mail.gmail.com> X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=0 tagged_above=0 required=5 tests=none X-Spam-Level: X-Archive-Number: 200903/37 X-Sequence-Number: 19367 Dave Cramer wrote: > > > On Mon, Mar 9, 2009 at 1:16 PM, Tom Lane > wrote: > > Guillaume Smet > writes: > > Unnamed prepared statements are planned after binding the values, > > starting with 8.3, or more precisely starting with 8.3.2 as early 8.3 > > versions were partially broken on this behalf. > > No, 8.2 did it too (otherwise we wouldn't have considered 8.3.0 to be > broken...). The thing I'm not too clear about is what "use of an > unnamed statement" translates to for a JDBC user. > > > Tom, > > The driver will use unnamed statements for all statements until it sees > the same statement N times where N is 5 I believe, after that it uses a > named statement. Right, with the caveat that "the same statement" means "exactly the same PreparedStatement object". If you happen to run the same (textual) query via two different PreparedStatement objects, they're still considered different queries for the purposes of this threshold. You can also tune the threshold via the prepareThreshold parameter in the driver URL, or use org.postgresql.PGStatement.setPrepareThreshold (an extension interface implemented by the driver on its Statement objects) on a per-statement basis. prepareThreshold=0 is a special value that means "never use a named statement". The idea behind the threshold is that if a PreparedStatement object is reused, that's a fairly good indication that the application wants to run the same query many times with different parameters (since it's going to the trouble of preserving the statement object for reuse). But it's all tunable if needed. Also see http://jdbc.postgresql.org/documentation/head/server-prepare.html -O