pg.ddx.io  pgsql-hackers@postgresql.org mailing list archive  

help / color / mirror / Atom feed
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Etsuro Fujita <fujita.etsuro@lab.ntt.co.jp>
Cc: Ashutosh Bapat <ashutosh.bapat@enterprisedb.com>
Cc: Jeff Janes <jeff.janes@gmail.com>
Cc: Robert Haas <robertmhaas@gmail.com>
Cc: pgsql-hackers <pgsql-hackers@postgresql.org>
Subject: Re: postgres_fdw bug in 9.6
Date: Mon, 19 Dec 2016 10:37:32 -0500
Message-ID: <10840.1482161852@sss.pgh.pa.us> (raw)
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>
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-hackers>

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



view thread (128+ messages)  latest in thread

Message-ID: <10840.1482161852@sss.pgh.pa.us>
Permalink:  ../10840.1482161852@sss.pgh.pa.us/
Also on:    postgresql.org/message-id/10840.1482161852@sss.pgh.pa.us

 · 

reply
Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-hackers@postgresql.org
  Cc: tgl@sss.pgh.pa.us, fujita.etsuro@lab.ntt.co.jp, ashutosh.bapat@enterprisedb.com, jeff.janes@gmail.com, robertmhaas@gmail.com
  Subject: Re: postgres_fdw bug in 9.6
  In-Reply-To: <10840.1482161852@sss.pgh.pa.us>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox