Re: [v9.5] Custom Plan API
От | Kohei KaiGai |
---|---|
Тема | Re: [v9.5] Custom Plan API |
Дата | |
Msg-id | CADyhKSU6FfJMuwBSHoimwTQ=ZUJyM8i_J4ru-7FaVOChhics9g@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [v9.5] Custom Plan API (Kohei KaiGai <kaigai@kaigai.gr.jp>) |
Список | pgsql-hackers |
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@kaigai.gr.jp>: > 2014-07-18 10:28 GMT+09:00 Kouhei Kaigai <kaigai@ak.jp.nec.com>: >>> Alvaro Herrera <alvherre@2ndquadrant.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@kaigai.gr.jp> -- KaiGai Kohei <kaigai@kaigai.gr.jp>
Вложения
В списке pgsql-hackers по дате отправления:
Следующее
От: Fujii MasaoДата:
Сообщение: Re: [patch] pg_copy - a command for reliable WAL archiving