Re: [v9.5] Custom Plan API
От | Kohei KaiGai |
---|---|
Тема | Re: [v9.5] Custom Plan API |
Дата | |
Msg-id | CADyhKSVJcy4kANk_ua0NV8V04LCFAX9Bpj5B7Uc7g7XFitfRJA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [v9.5] Custom Plan API (Kouhei Kaigai <kaigai@ak.jp.nec.com>) |
Ответы |
Re: [v9.5] Custom Plan API
|
Список | pgsql-hackers |
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>
Вложения
В списке pgsql-hackers по дате отправления: