Re: Custom/Foreign-Join-APIs (Re: [v9.5] Custom Plan API)
От | Shigeru Hanada |
---|---|
Тема | Re: Custom/Foreign-Join-APIs (Re: [v9.5] Custom Plan API) |
Дата | |
Msg-id | CAEZqfEdffdSXZfS-R5wgTMhrqrWSNCM6SJnxLCnHWwWe_M-_ig@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Custom/Foreign-Join-APIs (Re: [v9.5] Custom Plan API) (Kouhei Kaigai <kaigai@ak.jp.nec.com>) |
Список | pgsql-hackers |
2015-05-12 10:24 GMT+09:00 Kouhei Kaigai <kaigai@ak.jp.nec.com>: > option-2) > Tom's suggestion. Add a new list field of Path nodes on CustomPath, > then create_customscan_plan() will call static create_plan_recurse() > function to construct child plan nodes. > Probably, the attached patch will be an image of this enhancement, > but not tested yet, of course. Once we adopt this approach, I'll > adjust my PG-Strom code towards the new interface within 2 weeks > and report problems if any. +1. This design achieves the functionality required for custom join by Kaigai-san's use case, instantiating sub-plans of CustomScan plan recursively, without exposing create_plan_recurse. CSP can use the index number to distinguish information, like FDWs do with fdw_private. IMO it isn't necessary to apply the change onto ForeignPath/ForeignScan. FDW would have a way to keep-and-use sub paths as private information. In fact, I wrote postgres_fdw to use create_plan_recurse to generate SQL statements of inner/outer relations to be joined, but as of now SQL construction for join push-down is accomplished by calling private function deparseSelectSql recursively at the top of a join tree. Some FDW might hope to use sub-plan generation, but we don't have any concrete use case as of now. -- Shigeru HANADA
В списке pgsql-hackers по дате отправления: