On 4/6/17 9:04 AM, Peter Eisentraut wrote:
On 4/6/17 03:50, Craig Ringer wrote:
But otherwise, pending docs changes, I think it's ready for committer.
My opinion is still that this is ultimately the wrong approach. The
right fix for performance issues in PL/Python is to change PL/Python not
to materialize the list of tuples. Now with this change we would be
moving from two result materializations to one, but I think we are
keeping the wrong one.
That's an option for future improvement, but I see no way to accomplish
that without completely breaking plpy.
I think the best way to handle this would be to allow plpython functions
to define their own callback function, which would be handed a python
tuple that was translated from the SPI result tuple. How best to do that
without breaking plpy will require some thought though.
In the meantime, I don't think a 27% performance gain is anything to
sneeze at, and the SPI changes would be directly usable by pl/r and pl/tcl.
--
Jim C. Nasby, Data Architect j...@nasby.net
512.569.9461 (cell) http://jim.nasby.net
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
