Re: postgres_fdw bug in 9.6

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