|From:||Etsuro Fujita <fujita(dot)etsuro(at)lab(dot)ntt(dot)co(dot)jp>|
|To:||Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>|
|Cc:||Ashutosh Bapat <ashutosh(dot)bapat(at)enterprisedb(dot)com>, Jeff Janes <jeff(dot)janes(at)gmail(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>|
|Subject:||Re: postgres_fdw bug in 9.6|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
On 2016/12/20 0:37, Tom Lane wrote:
> Etsuro Fujita <fujita(dot)etsuro(at)lab(dot)ntt(dot)co(dot)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.
I'll have second thoughts about that. I agree with you except for that,
so I've created a patch; I removed GetExistingLocalJoinPath and added a
helper function, CreateLocalJoinPath, that generates a local join path
for a given foreign join, as described above. Please find attached a patch.
|Next Message||Robert Haas||2016-12-21 12:54:51||Re: [COMMITTERS] pgsql: Simplify LWLock tranche machinery by removing array_base/array_s|
|Previous Message||Artur Zakirov||2016-12-21 12:34:12||Re: Rethinking our fulltext phrase-search implementation|