On 2016/12/16 11:25, Etsuro Fujita wrote:
As I said upthread, an alternative I am thinking is (1) to create an
equivalent nestloop join path using inner/outer paths of a foreign join
path, except when that join path implements a full join, in which case a
merge/hash join path is used, (2) store it in fdw_outerpath as-is, and
(3) during an EPQ recheck, apply postgresRecheckForeignScan to the outer
subplan created from the fdw_outerpath as-is.  What do you think about
that?


Let me explain about #1 and #2 a bit more.  What I have in mind is:

* modify postgresGetForeignPaths so that a simple foreign table scan path is stored into the base relation's PgFdwRelationInfo.
* modify postgresGetForeignJoinPaths so that
(a) a local join path for a 2-way foreign join is created using simple foreign table scan paths stored in the base relations' PgFdwRelationInfos, and stored into the join relation's PgFdwRelationInfo. (b) a local join path for a 3-way foreign join, whose left input is a 2-way foreign join, is created using a local join path stored in the left input join relation's PgFdwRelationInfo and a simple foreign table scan path stored into the right input base relation's PgFdwRelationInfo.
    (c) Likewise for higher level foreign joins.
(d) local join paths created are passed to create_foreignscan_path and stored into the fdw_outerpaths of the resulting ForeignPahts.

I think that that would need special handling for foreign joins with sort orders; add an explicit sort to the local join paths, if needed.

I am thinking to provide a helper function that creates a local join path for (a), (b), and (c).

Best regards,
Etsuro Fujita




--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Reply via email to