Received: from localhost (unknown [200.46.204.183]) by postgresql.org (Postfix) with ESMTP id 44A7E9FB9F7 for ; Fri, 12 Oct 2007 05:06:00 -0300 (ADT) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.183]) (amavisd-maia, port 10024) with ESMTP id 55354-04 for ; Fri, 12 Oct 2007 05:05:52 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey-1.7.5 Received: from flame.co.za (rascal.co.za [160.124.170.1]) by postgresql.org (Postfix) with ESMTP id A32B59FBB89 for ; Fri, 12 Oct 2007 05:05:51 -0300 (ADT) Received: from [192.168.0.161] (unknown [196.209.202.75]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by flame.co.za (Postfix) with ESMTP id 7C1B4803F5 for ; Fri, 12 Oct 2007 10:05:38 +0200 (SAST) Subject: Re: Performance problems with prepared statements From: Theo Kramer Reply-To: theo@flame.co.za To: pgsql-performance@postgresql.org In-Reply-To: References: <1192027540.2495.3.camel@localhost.localdomain> <470CE918.4060608@dalibo.com> <1192044840.2549.21.camel@fedmac> Content-Type: text/plain Organization: Flame Computing Enterprises cc Date: Fri, 12 Oct 2007 10:05:35 +0200 Message-Id: <1192176335.2470.20.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.10.3 (2.10.3-4.fc7) Content-Transfer-Encoding: 7bit X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200710/144 X-Sequence-Number: 27166 On Thu, 2007-10-11 at 18:28 +0000, Andrew - Supernews wrote: > On 2007-10-10, Theo Kramer wrote: > > When doing a 'manual' prepare and explain analyze I get the following > > > > rascal=# prepare cq (char(12), smallint, integer) as SELECT oid, > > calllog_mainteng, calllog_phase, calllog_self FROM calllog > > WHERE calllog_mainteng = $1 > > AND calllog_phase = $2 > > AND calllog_self < $3 > > OR calllog_mainteng = $1 > > AND calllog_phase < $2 > > ORDER BY calllog_mainteng DESC, > > calllog_phase DESC, > > calllog_self DESC limit 25; > > PREPARE > > When you do this from the application, are you passing it 3 parameters, > or 5? The plan is clearly taking advantage of the fact that the two > occurrences of $1 and $2 are known to be the same value; if your app is > using some interface that uses ? placeholders rather than numbered > parameters, then the planner will not be able to make this assumption. You may just have hit the nail on the head. I use numbered parameters but have $1 to $5 ... let me take a look to see if I can change this. > Also, from the application, is the LIMIT 25 passed as a constant or is that > also a parameter? A constant. > -- Regards Theo