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
Subject: Re: Performance problems with prepared statements
Date: 2007-10-12 13:02:32
Message-ID: b42b73150710120602g2f47dd21lb851a72d05a184f1@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-performance
On 10/12/07, Theo Kramer <theo(at)flame(dot)co(dot)za> wrote:
> On Thu, 2007-10-11 at 16:04 -0400, Merlin Moncure wrote:
> >   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.

fwiw, I converted a pretty large cobol app (acucobol) to postgresql
backend translating queries on the fly.  if this is a fresh effort,
you definately want to use the row-wise comparison feature of 8.2.
not only is it much simpler, it's much faster.  with some clever
caching strategies i was able to get postgresql performance to exceed
the isam backend.  btw, I used execprepared for virtually the entire
system.

example read next:
select * from foo where (a,b,c) > (a1,b1,c1) order by a,b,c limit 25;

example read previous:
select * from foo where (a,b,c) < (a1,b1,c1) order by a desc, b desc,
c desc limit 25;

etc.  this will use complete index for a,b,c and is much cleaner to
prepare, and parse for the planner (the best you can get with standard
tactics is to get backend to use index on a).

Another big tip i can give you (also 8.2) is to check into advisory
locks for isam style pessimistic locking.  With some thin wrappers you
can generate full row and table locking which is quite powerful.

merlin

In response to

Responses

pgsql-performance by date

Next:From: Theo KramerDate: 2007-10-12 14:57:01
Subject: Re: Performance problems with prepared statements
Previous:From: Richard HuxtonDate: 2007-10-12 08:26:01
Subject: Re: Performance problems with prepared statements

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