From: Theo Kramer <theo@flame.co.za>
To: pgsql-performance@postgresql.org
Subject: Re: Performance problems with prepared statements
Date: Fri, 12 Oct 2007 09:35:02 +0200
Message-ID: <1192174502.2470.9.camel@localhost.localdomain> (raw)
In-Reply-To: <b42b73150710111304m161814cds984a7c525ff87241@mail.gmail.com>
References: <1192027540.2495.3.camel@localhost.localdomain>
<470CE918.4060608@dalibo.com>
<1192044840.2549.21.camel@fedmac>
<slrnfgsqpi.27gg.andrew+nonews@atlantis.supernews.net>
<b42b73150710111304m161814cds984a7c525ff87241@mail.gmail.com>
On Thu, 2007-10-11 at 16:04 -0400, Merlin Moncure wrote:
> On 10/11/07, Andrew - Supernews <andrew+nonews@supernews.com> wrote:
> > On 2007-10-10, Theo Kramer <theo@flame.co.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.
Agreed - and having a look into that.
> is this a converted cobol app?
:) - on the right track - it is a conversion from an isam based package
where I have changed the backed to PostgreSQL. Unfortunately there is
way too much legacy design and application code to change things at a
higher level.
--
Regards
Theo
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: theo@flame.co.za
Subject: Re: Performance problems with prepared statements
In-Reply-To: <1192174502.2470.9.camel@localhost.localdomain>
* 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