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