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
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 |