From: | "Robert Haas" <robertmhaas(at)gmail(dot)com> |
---|---|
To: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | "Martijn van Oosterhout" <kleptog(at)svana(dot)org>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: WIP patch: convert SQL-language functions to return tuplestores |
Date: | 2008-10-27 13:54:40 |
Message-ID: | 603c8f070810270654x5738c45fp5010e427657a7b0f@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
>> I thought that the bad case for a tuplestore was if the set returning
>> function was expensive and the user used it with a LIMIT clause. In the
>> tuplestore case you evaluate everything then throw it away.
>
> I'm not terribly excited by that example --- but in any case, the real
> solution to any problem that involves communication between function and
> calling query is to make sure that the function can get inlined into the
> query. That was an option we didn't have back in 8.2; but it's there
> now. My test case deliberately disables that optimization ...
I'm pretty excited by that example. LIMIT/OFFSET is really useful as
a way of paginating query results for display on a web page (show
results 1-100, 101-200, etc), and I use it on potentially expensive
SRFs just as I do on tables and views. I agree that inlining is a
better solution when it's possible, but who is to say that's always
the case? Of course if it's PL/pgsql with RETURN QUERY the way
forward is fairly obvious, but what if it isn't that simple?
...Robert
From | Date | Subject | |
---|---|---|---|
Next Message | Martin Pihlak | 2008-10-27 14:06:03 | SQL/MED compatible connection manager |
Previous Message | Tom Lane | 2008-10-27 13:25:28 | Re: Parsing errors in pg_hba.conf |