| From: | Craig Ringer <craig(at)2ndquadrant(dot)com> | 
|---|---|
| To: | Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)com> | 
| Cc: | Pg Hackers <pgsql-hackers(at)postgresql(dot)org>, Joe Conway <mail(at)joeconway(dot)com> | 
| Subject: | Re: Faster methods for getting SPI results | 
| Date: | 2016-12-28 09:14:20 | 
| Message-ID: | CAMsr+YG8e01eYdiRA-6y0JSXvRfxf7AROBF7pSmpFwYtqViO_w@mail.gmail.com | 
| Views: | Whole Thread | Raw Message | Download mbox | Resend email | 
| Thread: | |
| Lists: | pgsql-hackers | 
On 28 December 2016 at 12:32, Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)com> wrote:
> On 12/27/16 9:10 PM, Craig Ringer wrote:
>>
>> On 28 December 2016 at 09:58, Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Craig Ringer | 2016-12-28 10:00:37 | Re: [PATCH] Transaction traceability - txid_status(bigint) | 
| Previous Message | Ashutosh Bapat | 2016-12-28 08:34:06 | Re: postgres_fdw bug in 9.6 |