Re: Faster methods for getting SPI results (460% improvement)

From: Andres Freund <andres(at)anarazel(dot)de>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Jim Nasby <jim(dot)nasby(at)openscg(dot)com>, Craig Ringer <craig(at)2ndquadrant(dot)com>, Peter Eisentraut <peter(dot)eisentraut(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:21:05
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

On 2017-04-07 00:11:59 -0400, Tom Lane wrote:
> Jim Nasby <jim(dot)nasby(at)openscg(dot)com> writes:
> > On 4/6/17 8:13 PM, Tom Lane wrote:
> >> Given Peter's objections, I don't think this is getting into v10 anyway,
> >> so we might as well take a bit more time and do it right.
> > Well, Peter's objection is that we're not going far enough in plpython,
> > but there's absolutely no way to do more without breaking plpy, which
> > seems a non-starter. We should certainly be able to expand the existing
> > API to provide even more benefit, but I see no reason to leave the
> > performance gain this patch provides on the floor just because there's
> > more to be had with a different API.
> Personally I'm way more excited about what a SPI feature like this
> could do for plpgsql than about what it can do for plpython. If the
> latter is what floats your boat, that's fine; but I want a feature
> that we can build on for other uses, not a hack that we know we need
> to redesign next month.

Dislike of the proposed implementation, alternative proposals, and the
refutation of the "absolutely no way to do more without breaking plpy"
argument leads to me to conclude that this should be returned with

- Andres

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Kyotaro HORIGUCHI 2017-04-07 04:23:53 Re: Interval for launching the table sync worker
Previous Message Tatsuro Yamada 2017-04-07 04:12:31 Minor code improvement to postgresGetForeignPlan