Re: [HACKERS] Faster methods for getting SPI results (460%improvement)
От | Jim Nasby |
---|---|
Тема | Re: [HACKERS] Faster methods for getting SPI results (460%improvement) |
Дата | |
Msg-id | 5e377a1f-a167-7952-a078-209582ab3183@openscg.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] Faster methods for getting SPI results (460%improvement) (Andres Freund <andres@anarazel.de>) |
Список | 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 по дате отправления: