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: <b06b113e-73a1-fa5e-91b6-28bda2551a08@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>
Comments: In-reply-to Etsuro Fujita <fujita.etsuro@lab.ntt.co.jp>
	message dated "Thu, 15 Dec 2016 18:40:03 +0900"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <31739.1481819950.1@sss.pgh.pa.us>
Date: Thu, 15 Dec 2016 11:39:10 -0500
Message-ID: <31740.1481819950@sss.pgh.pa.us>
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org

Etsuro Fujita <fujita.etsuro@lab.ntt.co.jp> writes:
> On 2016/12/13 23:13, Ashutosh Bapat wrote:
>> On Tue, Dec 13, 2016 at 4:15 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>> One way that we could make things better is to rely on the knowledge
>>> that EPQ isn't asked to evaluate joins for more than one row per input
>>> relation, and therefore using merge or hash join technology is really
>>> overkill.  We could make a tree of simple nestloop joins, which aren't
>>> going to care about sort order, if we could identify the correct join
>>> clauses to apply.

>> I am not able to understand how this strategy of applying all join
>> clauses on top of cross product would work if there are OUTER joins
>> involved. Wouldn't nullable sides change the result?

> I'm not able to understand that, either.

Yeah, you'd have to reproduce the outer join structure if any.

>> A possible short-term fix may be this: instead of picking any random
>> path to stick into fdw_outerpath, we choose a path which covers the
>> pathkeys of ForeignPath.

> Seems reasonable.

No, because GetExistingLocalJoinPath is called once per relation not once
per path.  Even if we were willing to eat the overhead of calling it once
per path, we'd have to give up considering foreign paths with sort orders
that there wasn't any cheap way to produce locally.

			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