|From:||Kouhei Kaigai <kaigai(at)ak(dot)jp(dot)nec(dot)com>|
|To:||Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Robert Haas <robertmhaas(at)gmail(dot)com>|
|Cc:||Thom Brown <thom(at)linux(dot)com>, Kohei KaiGai <kaigai(at)kaigai(dot)gr(dot)jp>, "Shigeru Hanada" <shigeru(dot)hanada(at)gmail(dot)com>, "pgsql-hackers(at)postgreSQL(dot)org" <pgsql-hackers(at)postgresql(dot)org>|
|Subject:||Construction of Plan-node by CSP (RE: Custom/Foreign-Join-APIs)|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
> -----Original Message-----
> Sent: Friday, May 15, 2015 8:44 AM
> To: 'Tom Lane'; Kohei KaiGai
> Cc: Robert Haas; Thom Brown; Shigeru Hanada; pgsql-hackers(at)postgreSQL(dot)org
> Subject: RE: Custom/Foreign-Join-APIs (Re: [HACKERS] [v9.5] Custom Plan API)
> > A possible compromise that we could perhaps still wedge into 9.5 is to
> > extend CustomPath with a List of child Paths, and CustomScan with a List
> > of child Plans, which createplan.c would know to build from the Paths,
> > and other modules would then also be aware of these children. I find that
> > uglier than a separate join node type, but it would be tolerable I guess.
> The attached patch implements what you suggested as is.
> It allows custom-scan providers to have child Paths without exporting
> create_plan_recurse(), and enables to represent N-way join naturally.
> Please add any solution, even if we don't reach the consensus of how
> create_plan_recurse (and other useful static functions) are visible to
I updated the patch to fix up this problem towards the latest master
Let me remind the problem again. (I really have a hard time of it)
When an extension tries to implement its own join logic using custom-
scan interface, it adds CustomPath on set_join_pathlist_hook with its
Once the path gets chosen by planner, PlanCustomPath callback shall be
invoked, then, the custom-scan provider will construct its CustomScan
node according to the path, and I expected it recursively initializes
underlying Path nodes (that work as join input, if any) using
However, at this moment, we didn't get 100% consensus to export this
function to extensions. So, later commit made this function as static
Instead of this approach, Tom suggested to add a list of child Paths
on CustomPath node, then createplan.c calls create_plan_recurse() for
each entry of the list, without this function getting exported.
I can agree with this approach as an alternative of the previous
public create_plan_recurse(), and the attached patch implements this
idea, as is. (Do I understand his suggestion correctly?)
Below is the expectation of the custom-scan provider which takes
underlying Path/Plan nodes.
1. It adds a list of underlying Path nodes on custom_children of
the CustomPath node.
2. On the PlanCustomPath, it adds adds Plan nodes (initialized by
createplan.c, and passed as argument) onto lefttree, righttree
and/or custom_children of CustomScan node
3. On the BeginCustomScan, it calls ExecInitNode() to begin execution
of the underlying plan node. Then, if it has more than 2 children,
attach these PlanState objects on the custom_children list for
As long as extension follows the above interface contract, it can
have underlying child Path/Plan/PlanState without direct call of
create_plan_recurse() as previously argued.
I think it is enough reasonable solution for the problem.
How about people's thought?
NEC Business Creation Division / PG-Strom Project
KaiGai Kohei <kaigai(at)ak(dot)jp(dot)nec(dot)com>
|Next Message||alex2010||2015-05-25 09:13:34||about lob(idea)|
|Previous Message||Simon Riggs||2015-05-25 08:28:55||Re: 9.5 release notes may need ON CONFLICT DO NOTHING compatibility notice for FDW authors|