Re: Faster methods for getting SPI results (460% improvement)

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

In response to

Responses

Browse pgsql-hackers by date

  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)