Re: [HACKERS] Faster methods for getting SPI results (460%improvement) - Mailing list pgsql-hackers

From Andres Freund
Subject Re: [HACKERS] Faster methods for getting SPI results (460%improvement)
Date
Msg-id 20170407042105.4fuuzmj4r3eilcwe@alap3.anarazel.de
Whole thread Raw
In response to Re: [HACKERS] Faster methods for getting SPI results (460% improvement)  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: [HACKERS] Faster methods for getting SPI results (460%improvement)  (Jim Nasby <jim.nasby@openscg.com>)
List pgsql-hackers
On 2017-04-07 00:11:59 -0400, Tom Lane wrote:
> Jim Nasby <jim.nasby@openscg.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
feedback.

- Andres



pgsql-hackers by date:

Previous
From: Tatsuro Yamada
Date:
Subject: [HACKERS] Minor code improvement to postgresGetForeignPlan
Next
From: Kyotaro HORIGUCHI
Date:
Subject: Re: [HACKERS] Interval for launching the table sync worker