Skip site navigation (1) Skip section navigation (2)

Re: Performance problems with prepared statements

From: "Merlin Moncure" <mmoncure(at)gmail(dot)com>
To: theo(at)flame(dot)co(dot)za
Cc: pgsql-performance(at)postgresql(dot)org, andrew(at)supernews(dot)com
Subject: Re: Performance problems with prepared statements
Date: 2007-10-11 20:04:01
Message-ID: b42b73150710111304m161814cds984a7c525ff87241@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-performance
On 10/11/07, Andrew - Supernews <andrew+nonews(at)supernews(dot)com> wrote:
> On 2007-10-10, Theo Kramer <theo(at)flame(dot)co(dot)za> 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.
>
> Also, from the application, is the LIMIT 25 passed as a constant or is that
> also a parameter?

also, this looks a bit like a drilldown query, which is ordering the
table on 2+ fields.  if that's the case, row wise comparison is a
better and faster approach.  is this a converted cobol app?

merlin

In response to

Responses

pgsql-performance by date

Next:From: henk de witDate: 2007-10-11 23:21:35
Subject: Re: Huge amount of memory consumed during transaction
Previous:From: Andrew - SupernewsDate: 2007-10-11 18:28:02
Subject: Re: Performance problems with prepared statements

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group