Re: WIP patch: convert SQL-language functions to return tuplestores
От | Robert Haas |
---|---|
Тема | Re: WIP patch: convert SQL-language functions to return tuplestores |
Дата | |
Msg-id | 603c8f070810270654x5738c45fp5010e427657a7b0f@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: WIP patch: convert SQL-language functions to return tuplestores (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: WIP patch: convert SQL-language functions to return tuplestores
|
Список | 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
В списке pgsql-hackers по дате отправления: