From: Tom Lane <tgl@sss.pgh.pa.us>
To: Etsuro Fujita <fujita.etsuro@lab.ntt.co.jp>
cc: Ashutosh Bapat <ashutosh.bapat@enterprisedb.com>,
        Jeff Janes <jeff.janes@gmail.com>,
 Robert Haas <robertmhaas@gmail.com>,
        pgsql-hackers <pgsql-hackers@postgresql.org>
Subject: Re: postgres_fdw bug in 9.6
In-reply-to: <57825f66-9f11-0b0f-e4bf-e6608641c8e2@lab.ntt.co.jp>
References: 
 <CAMkU=1y2G8VOVBHv3iXU2TMAj7-RyBFFW1uhkr5sm9LQ2=X35g@mail.gmail.com>
 <6319.1481219450@sss.pgh.pa.us>
 <CA+TgmoZNpXHBp8yADNS7HST9OJAx4_MoZ5ckbxoFhSYo84nY2w@mail.gmail.com>
 <7784.1481221687@sss.pgh.pa.us>
 <CAMkU=1zEAryzjEa-njBkV2+uXXVHHk6u2V2eS1MT+zP7s=vj1Q@mail.gmail.com>
 <13242.1481582736@sss.pgh.pa.us>
 <CAFjFpRfYETZLiKERpxCeAN1MsiJypsyNd6x9FQ7OWjY=_TGK2Q@mail.gmail.com>
 <b06b113e-73a1-fa5e-91b6-28bda2551a08@lab.ntt.co.jp>
 <31740.1481819950@sss.pgh.pa.us>
 <c4d6d586-80cd-4328-7d92-0ea7a6b380d2@lab.ntt.co.jp>
 <f2684b07-b2e2-155b-b1e8-e141e89458b5@lab.ntt.co.jp>
 <12565.1481904788@sss.pgh.pa.us>
 <57825f66-9f11-0b0f-e4bf-e6608641c8e2@lab.ntt.co.jp>
Comments: In-reply-to Etsuro Fujita <fujita.etsuro@lab.ntt.co.jp>
	message dated "Mon, 19 Dec 2016 12:36:14 +0900"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <10839.1482161852.1@sss.pgh.pa.us>
Date: Mon, 19 Dec 2016 10:37:32 -0500
Message-ID: <10840.1482161852@sss.pgh.pa.us>
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org

Etsuro Fujita <fujita.etsuro@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