Re: [HACKERS] Faster methods for getting SPI results
| От | Craig Ringer |
|---|---|
| Тема | Re: [HACKERS] Faster methods for getting SPI results |
| Дата | |
| Msg-id | CAMsr+YG8e01eYdiRA-6y0JSXvRfxf7AROBF7pSmpFwYtqViO_w@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: [HACKERS] Faster methods for getting SPI results (Jim Nasby <Jim.Nasby@BlueTreble.com>) |
| Ответы |
Re: [HACKERS] Faster methods for getting SPI results
|
| Список | pgsql-hackers |
On 28 December 2016 at 12:32, Jim Nasby <Jim.Nasby@bluetreble.com> wrote: > On 12/27/16 9:10 PM, Craig Ringer wrote: >> >> On 28 December 2016 at 09:58, Jim Nasby <Jim.Nasby@bluetreble.com> wrote: >> >>> I've looked at this some more, and ITSM that the only way to do this >>> without >>> some major surgery is to create a new type of Destination specifically >>> for >>> SPI that allows for the execution of an arbitrary C function for each >>> tuple >>> to be sent. >> >> >> That sounds a lot more sensible than the prior proposals. Callback driven. > > > Are there other places this would be useful? I'm reluctant to write all of > this just to discover it doesn't help performance at all, but if it's useful > on it's own I can just submit it as a stand-alone patch. I don't have a use for it personally. In BDR and pglogical anything that does work with nontrivial numbers of tuples uses lower level scans anyway. I expect anything that uses the SPI to run arbitrary user queries could have a use for something like this though. Any PL, for one. -- Craig Ringer http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services
В списке pgsql-hackers по дате отправления: