From: | Jim Nasby <jim(dot)nasby(at)openscg(dot)com> |
---|---|
To: | Andres Freund <andres(at)anarazel(dot)de>, Jim Nasby <jim(at)nasby(dot)net> |
Cc: | Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, Craig Ringer <craig(at)2ndquadrant(dot)com>, 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-07 04:06:59 |
Message-ID: | 5fcb4926-64dd-2014-6af1-d8efbe26a559@openscg.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 4/6/17 9:04 PM, Andres Freund wrote:
> On 2017-04-06 09:14:43 -0700, Jim Nasby wrote:
>> 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.
>
> Why? We could very well return a somewhat "smarter" object. Returning
> rows row-by-row if accessed via iterator, materializes when accessed via
> row offset.
I completely agree with that. What I don't understand is the objection
to speeding up the old access method. Or are you thinking we'd just
abandon the old method?
--
Jim Nasby, Chief Data Architect, Austin TX
OpenSCG http://OpenSCG.com
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2017-04-07 04:07:59 | Re: src/interfaces/libpq shipping nmake-related Makefiles |
Previous Message | Andres Freund | 2017-04-07 04:06:13 | Re: src/interfaces/libpq shipping nmake-related Makefiles |