From: | Craig Ringer <craig(at)2ndquadrant(dot)com> |
---|---|
To: | Jim Nasby <jim(dot)nasby(at)openscg(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 (460% improvement) |
Date: | 2017-04-06 07:50:05 |
Message-ID: | CAMsr+YHxiXmYVsv01mfS-xTh5oc2KtHmK_=oD_1iPCF=KWskHw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 6 April 2017 at 15:38, Craig Ringer <craig(at)2ndquadrant(dot)com> wrote:
> Notes on the docs aside, I am pretty happy with this and think it's
> reasonable to proceed with it for Pg 10.
Actually, I'm a bit hesitant about returning a static struct that you
expect callers to copy and modify. But it seems to be an issue with
CreateDestReceiver's interface where it mixes returning pointers to
static structs with returning pointers to palloc'd memory, not a new
issue added by this patch.
I think you're better off bypassing CreateDestReceiver here, and doing
what CreateTransientRelDestReceiver(), etc do directly instead. That
way there's no need for the hoop jumping of returning a pointer to a
static struct to memcpy() into another struct in:
+ memcpy(&(callback->pub), CreateDestReceiver(DestSPICallback),
sizeof(DestReceiver));
Just document that the spi callback struct must have DestReciever as
its first member and must be palloc0'd.
But otherwise, pending docs changes, I think it's ready for committer.
--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Kyotaro HORIGUCHI | 2017-04-06 07:50:56 | Re: [COMMITTERS] pgsql: Collect and use multi-column dependency stats |
Previous Message | Craig Ringer | 2017-04-06 07:38:17 | Re: Faster methods for getting SPI results (460% improvement) |