| From: | Jim Nasby <jim(at)nasby(dot)net> |
|---|---|
| To: | Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, Craig Ringer <craig(at)2ndquadrant(dot)com>, Jim Nasby <jim(dot)nasby(at)openscg(dot)com> |
| Cc: | Pg Hackers <pgsql-hackers(at)postgresql(dot)org>, Joe Conway <mail(at)joeconway(dot)com> |
| Subject: | Re: Faster methods for getting SPI results (460% improvement) |
| Date: | 2017-04-06 16:14:43 |
| Message-ID: | 53431419-e6fe-ea72-b49b-64f332d79de5@nasby.net |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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 jim(at)nasby(dot)net
512.569.9461 (cell) http://jim.nasby.net
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Petr Jelinek | 2017-04-06 16:33:43 | Re: subscription worker doesn't start immediately on eabled |
| Previous Message | Peter Eisentraut | 2017-04-06 16:10:36 | Re: background sessions |