Re: [v9.5] Custom Plan API

The attached patch is the rebased custom-plan api, without any
functional changes
from the latest version; that added a flag field to custom-plan node
to show whether
it support mark/restore or backward-scan.

Towards the upcoming commit-fest, let me summarize the brief overview
of this patch.

The purpose of custom-plan interface, implemented with this patch, is to allow
extensions to provide alternative way to scan (and potentially joining
and so on)
relation, in addition to the built-in logic.
If one or more extensions are installed as custom-plan provider, it
can tell the planner
alternative way to scan a relation using CustomPath node with cost estimation.
As usual manner, the planner will chose a particular path based on the cost.
If custom one would not be chosen, it's gone and nothing different.
Once a custom-plan gets chosen, the custom-plan provider that performs on behalf
of the custom-plan node shall be invoked during query execution. It is
responsible to
scan the relation by its own way.
One expected usage of this interface is GPU acceleration that I'm working also.

The custom-plan provider shall be invoked via the function being
installed as custom-
plan provider, with an argument that packs all the necessary
information to construct
a custom-path node. In case of relation scan, customScanArg that contains
PlannerInfo, RelOptInfo and RangeTblEntry shall be informed.
The function is registered using a new command:
CREATE CUSTOM PLAN PROVIDER <name>
FOR SCAN HANDLER <handler_funtion>;

According to the discussion before, CustomXXX node is designed to have private
fields of extension like a manner of object oriented language.
CustomXXX node has a few common and minimum required fields, but no private
pointer. Extension declares its own Path/Plan/PlanState structure that inherits
CustomXXX node on the head of structure declaration, but not all. It can have
private fields on the later half of the structure.
The contrib/ctidscan is a good example to see how extension can utilize the
interface.

Once a CustomPlan/PlanState node is constructed, the rest of processes are
what other executor-nodes are doing. It shall be invoked at beginning, ending
and running of the executor, then callback function in the table of function
pointers shall be called.

Thanks,

2014-07-23 10:47 GMT+09:00 Kohei KaiGai <kaigai(at)kaigai(dot)gr(dot)jp>:
> 2014-07-18 10:28 GMT+09:00 Kouhei Kaigai <kaigai(at)ak(dot)jp(dot)nec(dot)com>:
>>> Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> writes:
>>> > I haven't followed this at all, but I just skimmed over it and noticed
>>> > the CustomPlanMarkPos thingy; apologies if this has been discussed
>>> > before. It seems a bit odd to me; why isn't it sufficient to have a
>>> > boolean flag in regular CustomPlan to indicate that it supports
>>> > mark/restore?
>>>
>>> Yeah, I thought that was pretty bogus too, but it's well down the list of
>>> issues that were there last time I looked at this ...
>>>
>> IIRC, CustomPlanMarkPos was suggested to keep the interface of
>> ExecSupportsMarkRestore() that takes plannode tag to determine
>> whether it support Mark/Restore.
>> As my original proposition did, it seems to me a flag field in
>> CustomPlan structure is straightforward, if we don't hesitate to
>> change ExecSupportsMarkRestore().
>>
> The attached patch revised the above point.
> It eliminates CustomPlanMarkPos, and adds flags field on CustomXXX
> structure to inform the backend whether the custom plan provider can
> support mark-restore position and backward scan.
> This change requires ExecSupportsMarkRestore() to reference
> contents of Path node, not only node-tag, so its declaration was also
> changed to take a pointer to Path node.
> The only caller of this function is final_cost_mergejoin() right now.
> It just gives pathtype field of Path node on its invocation, so this change
> does not lead significant degradation.
>
> Thanks,
> --
> KaiGai Kohei <kaigai(at)kaigai(dot)gr(dot)jp>

--
KaiGai Kohei <kaigai(at)kaigai(dot)gr(dot)jp>