From: | Gregory Stark <stark(at)enterprisedb(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | "Robert Haas" <robertmhaas(at)gmail(dot)com>, "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-28 10:23:34 |
Message-ID: | 87k5btc921.fsf@oxford.xeocode.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
> "Robert Haas" <robertmhaas(at)gmail(dot)com> writes:
>> 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 suspect it doesn't help you as much as you think. It's always been
> the case that SRFs in FROM-items are fed through a tuplestore, and so
> are plpgsql SRF results.
I always thought we considered that a bug though. It sure would be nice if we
could generate results as needed instead of having to generate them in advance
and store all of them.
In particular I fear there are a lot of places that use functions where we
might expect them to use views. They're never going to get really good plans
but it would be nice if we could at least avoid the extra materialize steps.
Now your patch isn't affecting that one way or the other but does it rule it
out forever?
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
Ask me about EnterpriseDB's RemoteDBA services!
From | Date | Subject | |
---|---|---|---|
Next Message | Simon Riggs | 2008-10-28 10:50:09 | Re: WIP patch: convert SQL-language functions to return tuplestores |
Previous Message | Simon Riggs | 2008-10-28 10:10:45 | Re: VACUUMs and WAL |