X-Original-To: pgsql-performance-postgresql.org@localhost.postgresql.org
Received: from localhost (av.hub.org [200.46.204.144])
	by postgresql.org (Postfix) with ESMTP id 2B05111F6C7D
	for <pgsql-performance-postgresql.org@localhost.postgresql.org>;
	Tue, 11 Apr 2006 04:58:39 -0300 (ADT)
X-Virus-Scanned: by amavisd-new at hub.org
X-Spam-Score: 0.121
X-Spam-Level: 
X-Spam-Status: No, score=0.121 required=5 tests=[AWL=0.120,
 HTML_MESSAGE=0.001]
Received: from postgresql.org ([200.46.204.71])
	by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024)
	with ESMTP id foPI+j9919nP
	for <pgsql-performance-postgresql.org@localhost.postgresql.org>;
	Tue, 11 Apr 2006 04:58:32 -0300 (ADT)
X-Greylist: domain auto-whitelisted by SQLgrey-
Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.226])
	by postgresql.org (Postfix) with ESMTP id 3B48D11F6C74
	for <pgsql-performance@postgresql.org>;
	Tue, 11 Apr 2006 04:58:33 -0300 (ADT)
Received: by wproxy.gmail.com with SMTP id i12so981944wra
	for <pgsql-performance@postgresql.org>;
	Tue, 11 Apr 2006 00:58:34 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com;
	h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references;
	b=MkTEBPh3T+6AD4rX+i4t2znrY/9VVnQfJHGjwUX+/E/26FGNGzz3XmzJNfLLBXRRYDYJx9Ik49c6SILB0SAL5uTy9hmbH5jK/ZyBBRqWSBzVxwi25hy8TOKkv9I6L4syPSFy/nr2wjvM4d9r0Qw6r0u6snGyy0bjmfMQQmOeNnI=
Received: by 10.65.61.13 with SMTP id o13mr254622qbk;
	Tue, 11 Apr 2006 00:58:33 -0700 (PDT)
Received: by 10.65.61.19 with HTTP; Tue, 11 Apr 2006 00:58:33 -0700 (PDT)
Message-ID: <9e4684ce0604110058r371c5dbib531d5409a47a399@mail.gmail.com>
Date: Tue, 11 Apr 2006 09:58:33 +0200
From: "hubert depesz lubaczewski" <depesz@gmail.com>
To: "Simon Dale" <sdale@rm.com>
Subject: Re: Stored Procedure Performance
Cc: pgsql-performance@postgresql.org
In-Reply-To: 
 <416F947BF5BA9E40B5F9AA649422212E074DE930@ex-mail2.internal.rmplc.net>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_Part_1965_21816926.1144742313934"
References: 
 <416F947BF5BA9E40B5F9AA649422212E074DE930@ex-mail2.internal.rmplc.net>
X-Archive-Number: 200604/228
X-Sequence-Number: 18312

------=_Part_1965_21816926.1144742313934
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

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 a=
nd
> I was wondering if it is usual for stored procedures to perform slower on
> PostgreSQL than raw SQL?
>

worry but your benchmark is completelly flawed.
1st. the tables are empty. will you ever run the real code on empty tables?
2nd. do you really need a stored procedure for such a simple query?

testing something that's far from real usage will not give you any good.
return next will of course show up as slower than standard select. the thin=
g
is - will the relative slowness of return next matter to you when you will
put more logic in the procedure?

depesz

------=_Part_1965_21816926.1144742313934
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

On 4/11/06, <b class=3D"gmail_sendername">Simon Dale</b> &lt;<a href=3D"mai=
lto:sdale@rm.com">sdale@rm.com</a>&gt; wrote:<div><span class=3D"gmail_quot=
e"></span><blockquote class=3D"gmail_quote" style=3D"border-left: 1px solid=
 rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div style=3D"direction: ltr;">












<div><p><font face=3D"Arial" size=3D"2"><span style=3D"font-size: 10pt; fon=
t-family: Arial;">I'm trying to evaluate PostgreSQL as a database that
will have to store a high volume of data and access that data frequently. O=
ne
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?</span></font></p></div></div></b=
lockquote></div><br>worry but your benchmark is completelly flawed.<br>1st.=
 the tables are empty. will you ever run the real code on empty tables?
<br>2nd. do you really need a stored procedure for such a simple query?<br>=
<br>testing something that's far from real usage will not give you any good=
.<br>return next will of course show up as slower than standard select. the=
 thing is - will the relative slowness of return next matter to you when yo=
u will put more logic in the procedure?
<br><br>depesz<br>

------=_Part_1965_21816926.1144742313934--