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 | 026912E3-2722-4F6E-B4F0-7AB108E91FB4@gmail.com обсуждение исходный текст |
Ответ на | Re: Custom/Foreign-Join-APIs (Re: [v9.5] Custom Plan API) (Kouhei Kaigai <kaigai@ak.jp.nec.com>) |
Ответы |
Re: Custom/Foreign-Join-APIs (Re: [v9.5] Custom Plan API)
|
Список | pgsql-hackers |
2015/03/26 10:51、Kouhei Kaigai <kaigai@ak.jp.nec.com> のメール: > The attached patch adds GetForeignJoinPaths call on make_join_rel() only when > 'joinrel' is actually built and both of child relations are managed by same > FDW driver, prior to any other built-in join paths. > I adjusted the hook definition a little bit, because jointype can be reproduced > using SpecialJoinInfo. Right? OK. > > Probably, it will solve the original concern towards multiple calls of FDW > handler in case when it tries to replace an entire join subtree with a foreign- > scan on the result of remote join query. > > How about your opinion? Seems fine. I’ve fixed my postgres_fdw code to fit the new version, and am working on handling a whole-join-tree. It would be difficult in the 9.5 cycle, but a hook point where we can handle whole joinrel might allow us to optimize a querywhich accesses multiple parent tables, each is inherited by foreign tables and partitioned with identical join key,by building a path tree which joins sharded tables first, and then union those results. -- Shigeru HANADA shigeru.hanada@gmail.com
В списке pgsql-hackers по дате отправления: