Richard Huxton <[EMAIL PROTECTED]> writes:
> Ah, fair enough. I *am* right in thinking that trivial SQL functions
> will have their expressions inlined though?
Yes.
regards, tom lane
---(end of broadcast)---
TIP 5: don't fo
Tom Lane wrote:
Richard Huxton <[EMAIL PROTECTED]> writes:
I must say I thought recent versions of PG delayed planning the query
until first call though.
No, you're thinking of parameterized queries sent through the FE/BE
protocol. Functions still plan without any assumptions about parameter
Richard Huxton <[EMAIL PROTECTED]> writes:
> I must say I thought recent versions of PG delayed planning the query
> until first call though.
No, you're thinking of parameterized queries sent through the FE/BE
protocol. Functions still plan without any assumptions about parameter
values.
Scott Schulthess wrote:
Hey Ya'll,
I'm a little puzzled by the speed of the stored procedures I am writing.
Here is the query alone in pgAdmin
select distinct featuretype from gnis_placenames where state='CT'
TIME: 312+16ms
Here is a stored procedure
create or replace function getfeature
Hey Ya'll,
I'm a little puzzled by the speed of the stored procedures I am writing.
Here is the query alone in pgAdmin
select distinct featuretype from gnis_placenames where state='CT'
TIME: 312+16ms
Here is a stored procedure
create or replace function getfeaturetypes(text) r
