Etsuro Fujita <fujita.ets...@lab.ntt.co.jp> writes:
> On 2016/12/17 1:13, Tom Lane wrote:
>> So I think the rule could be
>> "When first asked to produce a path for a given foreign joinrel, collect
>> the cheapest paths for its left and right inputs, and make a nestloop path
>> (or hashjoin path, if full join) from those, using the join quals needed
>> for the current input relation pair.
> Seems reasonable.
>> Use this as the fdw_outerpath for
>> all foreign paths made for the joinrel."
> I'm not sure that would work well for foreign joins with sort orders.
> Consider a merge join, whose left input is a 2-way foreign join with a
> sort order that implements a full join and whose right input is a sorted
> local table scan. If the EPQ subplan for the foreign join wouldn't
> produce the right sort order, the merge join might break during EPQ
> rechecks (note that in this case the EPQ subplan for the foreign join
> might produce more than a single row during an EPQ recheck).
How so? We only recheck one row at a time, therefore it can be claimed to
have any sort order you care about.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
