Re: postgres_fdw bug in 9.6

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Etsuro Fujita <fujita(dot)etsuro(at)lab(dot)ntt(dot)co(dot)jp>
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
Date: 2016-12-19 15:37:32
Message-ID: 10840.1482161852@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrew Borodin 2016-12-19 16:30:32 Re: pg_background contrib module proposal
Previous Message Steve Singer 2016-12-19 14:39:09 Re: Logical Replication WIP