| From: | Andres Freund <andres(at)anarazel(dot)de> |
|---|---|
| To: | Jim Nasby <jim(at)nasby(dot)net> |
| Cc: | 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>, 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:04:45 |
| Message-ID: | 20170407040445.ck5vxkvtmnqacl63@alap3.anarazel.de |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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.
- Andres
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andres Freund | 2017-04-07 04:06:13 | Re: src/interfaces/libpq shipping nmake-related Makefiles |
| Previous Message | Tom Lane | 2017-04-07 04:01:01 | Re: src/interfaces/libpq shipping nmake-related Makefiles |