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

From Jim Nasby
Subject Re: [HACKERS] Faster methods for getting SPI results (460%improvement)
Date
Msg-id 5e377a1f-a167-7952-a078-209582ab3183@openscg.com
Whole thread Raw
In response to Re: [HACKERS] Faster methods for getting SPI results (460%improvement)  (Andres Freund <andres@anarazel.de>)
List pgsql-hackers
On 4/6/17 9:21 PM, Andres Freund wrote:
>> 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.

Yeah, I thought about plpgsql and I can't see any way to make that work 
through an SPI callback (perhaps just due to my ignorance on things C). 
I suspect what plpgsql actually wants is a way to tell SPI to start the 
executor up, a function that pulls individual tuples out of the 
executor, and then a function to shut the executor down.

> 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.

Agreed.
-- 
Jim Nasby, Chief Data Architect, Austin TX
OpenSCG                 http://OpenSCG.com



pgsql-hackers by date:

Previous
From: Kyotaro HORIGUCHI
Date:
Subject: Re: [HACKERS] Interval for launching the table sync worker
Next
From: Pavan Deolasee
Date:
Subject: Re: [HACKERS] Patch: Write Amplification Reduction Method (WARM)