Re: [v9.5] Custom Plan API

> On 8 May 2014 22:55, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> >> We're past the prototyping stage and into productionising what we
> >> know works, AFAIK. If that point is not clear, then we need to
> >> discuss that first.
> >
> > OK, I'll bite: what here do we know works? Not a damn thing AFAICS;
> > it's all speculation that certain hooks might be useful, and
> > speculation that's not supported by a lot of evidence. If you think
> > this isn't prototyping, I wonder what you think *is* prototyping.
>
> My research contacts advise me of this recent work
> http://www.ntu.edu.sg/home/bshe/hashjoinonapu_vldb13.pdf
> and also that they expect a prototype to be ready by October, which I have
> been told will be open source.
>
> So there are at least two groups looking at this as a serious option for
> Postgres (not including the above paper's authors).
>
> That isn't *now*, but it is at least a time scale that fits with acting
> on this in the next release, if we can separate out the various ideas and
> agree we wish to proceed.
>
> I'll submerge again...
>
Through the discussion last week, our minimum consensus are:
1. Deregulated enhancement of FDW is not a way to go
2. Custom-path that can replace built-in scan makes sense as a first step
towards the future enhancement. Its planner integration is enough simple
to do.
3. Custom-path that can replace built-in join takes investigation how to
integrate existing planner structure, to avoid (3a) reinvention of
whole of join handling in extension side, and (3b) unnecessary extension
calls towards the case obviously unsupported.

So, I'd like to start the (2) portion towards the upcoming 1st commit-fest
on the v9.5 development cycle. Also, we will be able to have discussion
for the (3) portion concurrently, probably, towards 2nd commit-fest.

Unfortunately, I cannot participate PGcon/Ottawa this year. Please share
us the face-to-face discussion here.

Thanks,
--
NEC OSS Promotion Center / PG-Strom Project
KaiGai Kohei <kaigai(at)ak(dot)jp(dot)nec(dot)com>