From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Martijn van Oosterhout <kleptog(at)svana(dot)org> |
Cc: | pgsql-hackers(at)postgreSQL(dot)org |
Subject: | Re: WIP patch: convert SQL-language functions to return tuplestores |
Date: | 2008-10-27 12:02:23 |
Message-ID: | 13894.1225108943@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Martijn van Oosterhout <kleptog(at)svana(dot)org> writes:
> On Sun, Oct 26, 2008 at 09:49:49PM -0400, Tom Lane wrote:
>> So I'm concluding that we can easily afford to switch to tuplestore-always
>> operation, especially if we are willing to put any effort into tuplestore
>> optimization.
> 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 ...
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Heikki Linnakangas | 2008-10-27 12:03:35 | Visibility map, partial vacuums |
Previous Message | Stephen R. van den Berg | 2008-10-27 11:59:37 | Re: Full socket send buffer prevents cancel, timeout |