From: | Mark Kirkwood <markir(at)slingshot(dot)co(dot)nz> |
---|---|
To: | Jaros?aw Nozderko <jaroslaw(dot)nozderko(at)polkomtel(dot)com(dot)pl>, Joe Conway <mail(at)joeconway(dot)com> |
Cc: | "Pgsql-General (E-mail)" <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: Stored procedures returning rowsets |
Date: | 2002-08-13 09:21:23 |
Message-ID: | 3D58CF90.2060904@slingshot.co.nz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Previously
>Perhaps not all these factors are always important, but in big and
>heavy loaded systems it's really unimaginable to send "raw" queries.
Interesting,
I have heard this often... mainly from SQL Server folk....
I find it hard to understand what is bad about "raw" sql.... here is why :
As I understand it, every query goes through the stages of
parse,execute, [and possibly fetch(es)].
Stored procedures can only save you the parse phase (at best) - which is
usually a tiny component of the total cost/elapsed time (and when it is
not, then you probably have a data warehouse with an ad-hoc query tool
issueing complex queries - which is not ameniable to the use of
procedures either).
Furthur several databases managers save (or provide methods to) the
parse tree for a query class (Oracle and DB2 for instance), so in these
cases there is zero difference in performance between "raw" and
"procedured" sql.
I dont want to do a "bash SQL Server" thing here (as its quite a good
product)...but I do wonder if it has a very expensive parse phase.
regards
Mark
From | Date | Subject | |
---|---|---|---|
Next Message | Mario Weilguni | 2002-08-13 09:40:13 | Re: Stored procedures returning rowsets |
Previous Message | Martijn van Oosterhout | 2002-08-13 08:43:55 | Re: Slow deletes |