Andrew Dunstan wrote:
> Florian G. Pflug wrote:
>> Just a thought - I believe that there are portable user-space thread
>> implementations that contain little or no machine-specific code. What
>> if postgres used one of those to switch from the PL into the executor
>> and back after, say, 1000 rows were returned by the SFR?
>>
>> What would be needed is basically some enhanced version of setjmp/longjmp
>> that actually saves the stack, and not just resets the stackpointer.
>>
>> Since context switching would occur only at two well-defined places
>> (Some return_next_row function that PLs call when a SFR returns a row,
>> and in the executor if no more previously returned rows from that SFR
>> are available), this wouldn't introduce the usual multithreading
>> headache, but still allow to switch in and out of the PL interpreter.
>>
>>
> This just sounds horribly fragile.
Why would it be? It's about the same as running postgresql in one thread,
and some PL in another. This should only cause trouble if both use some
non-reentrant libc-functions. But even that wouldn't matter because of
the well-defined context switching points.
Here is a paper about portable userspace threads that I just googled.
http://www.gnu.org/software/pth/rse-pmt.ps
> Are we really sure that this isn't a solution in search of a problem?
I think this really depends on how you define "problem". Some people
might think that "select * from myfunc(...) limit 1" should stop and
return a result after myfunc(...) has returned one row. Others will
say "well, just use a different software design that doesn't depend
on this optimization".
greetings, Florian Pflug