2015/03/25 18:53、Ashutosh Bapat <ashutosh.ba...@enterprisedb.com> のメール：
>
>
> On Wed, Mar 25, 2015 at 3:14 PM, Shigeru HANADA <shigeru.han...@gmail.com>
> wrote:
>
> Or bottom of make_join_rel(). IMO build_join_rel() is responsible for just
> building (or searching from a list) a RelOptInfo for given relids. After
> that make_join_rel() calls add_paths_to_joinrel() with appropriate arguments
> per join type to generate actual Paths implements the join. make_join_rel()
> is called only once for particular relid combination, and there
> SpecialJoinInfo and restrictlist (conditions specified in JOIN-ON and WHERE),
> so it seems promising for FDW cases.
>
> I like that idea, but I think we will have complex hook signature, it won't
> remain as simple as hook (root, joinrel).
Signature of the hook (or the FDW API handler) would be like this:
typedef void (*GetForeignJoinPaths_function ) (PlannerInfo *root,
RelOptInfo *joinrel,
RelOptInfo *outerrel,
RelOptInfo *innerrel,
JoinType jointype,
SpecialJoinInfo *sjinfo,
List *restrictlist);
This is very similar to add_paths_to_joinrel(), but lacks semifactors and
extra_lateral_rels. semifactors can be obtained with
compute_semi_anti_join_factors(), and extra_lateral_rels can be constructed
from root->placeholder_list as add_paths_to_joinrel() does.
>From the viewpoint of postgres_fdw, jointype and restrictlist is necessary to
>generate SELECT statement, so it would require most work done in make_join_rel
>again if the signature was hook(root, joinrel). sjinfo will be necessary for
>supporting SEMI/ANTI joins, but currently it is not in the scope of
>postgres_fdw.
I guess that other FDWs require at least jointype and restrictlist.
—
Shigeru HANADA
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
