| From: | Alvaro Herrera <alvherre(at)commandprompt(dot)com> |
|---|---|
| To: | Merlin Moncure <mmoncure(at)gmail(dot)com> |
| Cc: | Simon Dale <sdale(at)rm(dot)com>, pgsql-performance(at)postgresql(dot)org |
| Subject: | Re: Stored Procedure Performance |
| Date: | 2006-04-11 14:08:57 |
| Message-ID: | 20060411140857.GE11760@surnet.cl |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
Merlin Moncure wrote:
> 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.
There's one problem that hasn't been mentioned. For the optimizer a
PL/pgSQL function (really, a function in any language except SQL) is a
black box. If you have a complex join of two or three functions, and
they don't return 1000 rows, it's very likely that the optimizer is
going to get it wrong.
--
Alvaro Herrera http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Markus Schaber | 2006-04-11 17:59:39 | Re: Indexes with descending date columns |
| Previous Message | H.J. Sanders | 2006-04-11 14:02:51 | Re: Stored Procedure Performance |