From: | Shigeru HANADA <shigeru(dot)hanada(at)gmail(dot)com> |
---|---|
To: | Kouhei Kaigai <kaigai(at)ak(dot)jp(dot)nec(dot)com> |
Cc: | Ashutosh Bapat <ashutosh(dot)bapat(at)enterprisedb(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Thom Brown <thom(at)linux(dot)com>, "pgsql-hackers(at)postgreSQL(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Custom/Foreign-Join-APIs (Re: [v9.5] Custom Plan API) |
Date: | 2015-03-26 03:04:47 |
Message-ID: | 026912E3-2722-4F6E-B4F0-7AB108E91FB4@gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
2015/03/26 10:51、Kouhei Kaigai <kaigai(at)ak(dot)jp(dot)nec(dot)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 query which 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(dot)hanada(at)gmail(dot)com
From | Date | Subject | |
---|---|---|---|
Next Message | Venkata Balaji N | 2015-03-26 03:23:10 | Re: pg_rewind in contrib |
Previous Message | Amit Kapila | 2015-03-26 02:59:09 | Re: Parallel Seq Scan |