|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)|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
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
|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|