Date: Tue, 11 Apr 2006 10:08:57 -0400
From: Alvaro Herrera <alvherre@commandprompt.com>
To: Merlin Moncure <mmoncure@gmail.com>
Cc: Simon Dale <sdale@rm.com>, pgsql-performance@postgresql.org
Subject: Re: Stored Procedure Performance
Message-ID: <20060411140857.GE11760@surnet.cl>
Mail-Followup-To: Merlin Moncure <mmoncure@gmail.com>,
	Simon Dale <sdale@rm.com>, pgsql-performance@postgresql.org
References: 
 <416F947BF5BA9E40B5F9AA649422212E074DE930@ex-mail2.internal.rmplc.net>
	<b42b73150604110649r3443a561x48dba1b9dc28703f@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <b42b73150604110649r3443a561x48dba1b9dc28703f@mail.gmail.com>
User-Agent: Mutt/1.5.11+cvs20060330

Merlin Moncure wrote:
> On 4/11/06, Simon Dale <sdale@rm.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.