Re: Stored Procedure Performance

From: "Merlin Moncure" <mmoncure(at)gmail(dot)com>
To: "Simon Dale" <sdale(at)rm(dot)com>
Cc: pgsql-performance(at)postgresql(dot)org
Subject: Re: Stored Procedure Performance
Date: 2006-04-11 13:49:48
Message-ID: b42b73150604110649r3443a561x48dba1b9dc28703f@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

On 4/11/06, Simon Dale <sdale(at)rm(dot)com> wrote:
> I'm trying to evaluate PostgreSQL as a database that will have to store a
> high volume of data and access that data frequently. One of the features on
> our wish list is to be able to use stored procedures to access the data and
> I was wondering if it is usual for stored procedures to perform slower on
> PostgreSQL than raw SQL?

pl/pgsql procedures are a very thin layer over the query engine.
Generally, they run about the same speed as SQL but you are not making
apples to apples comparison. One of the few but annoying limitations
of pl/pgsql procedures is that you can't return a select directly from
the query engine but have to go through the return/return next
paradigm which will be slower than raw query for obvious reasons.

You can however return a refcursor and you may want to look at them in
situations where you want to return arbitrary sets outside the query
engine or between pl/pgsql functions. An example of using refcurors
in that way is on my blog at
http://people.planetpostgresql.org/merlin/index.php?/archives/2-Dealing-With-Recursive-Sets-With-PLPGSQL.html

Generally, in my opinion if you want to really unlock the power of
postgresql you have to master pl/pgsql. Go for it...it will work and
work well.

merlin

merlin

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Christopher Browne 2006-04-11 13:56:27 Re: Stored Procedure Performance
Previous Message Tom Lane 2006-04-11 13:45:36 Re: Takes too long to fetch the data from database