Received: from malur.postgresql.org ([217.196.149.56])
	by arkaria.postgresql.org with esmtp (Exim 4.84)
	(envelope-from
 <pgsql-hackers-owner+M293638=pgsql-hackers-arkari@postgresql.org>)
	id 1aelpV-0001pX-Pf
	for pgsql-hackers@arkaria.postgresql.org; Sat, 12 Mar 2016 15:51:49 +0000
Received: from localhost ([127.0.0.1] helo=postgresql.org)
	by malur.postgresql.org with smtp (Exim 4.84)
	(envelope-from
 <pgsql-hackers-owner+M293638=pgsql-hackers-arkari@postgresql.org>)
	id 1aelpV-0000yL-Bl
	for pgsql-hackers@arkaria.postgresql.org; Sat, 12 Mar 2016 15:51:49 +0000
Received: from makus.postgresql.org ([2001:4800:1501:1::229])
	by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256)
	(Exim 4.84)
	(envelope-from <tgl@sss.pgh.pa.us>)
	id 1aelpU-0000y3-MS
	for pgsql-hackers@postgresql.org; Sat, 12 Mar 2016 15:51:48 +0000
Received: from sss.pgh.pa.us ([66.207.139.130])
	by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256)
	(Exim 4.84)
	(envelope-from <tgl@sss.pgh.pa.us>)
	id 1aelpO-0000pb-3Z
	for pgsql-hackers@postgresql.org; Sat, 12 Mar 2016 15:51:47 +0000
Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1])
	by sss.pgh.pa.us (8.14.4/8.14.4) with ESMTP id u2CFpd5b013158;
	Sat, 12 Mar 2016 10:51:39 -0500
From: Tom Lane <tgl@sss.pgh.pa.us>
To: "David G. Johnston" <david.g.johnston@gmail.com>
cc: David Rowley <david.rowley@2ndquadrant.com>,
        Tomas Vondra <tomas.vondra@2ndquadrant.com>,
        Simon Riggs <simon@2ndquadrant.com>,
        PostgreSQL-development <pgsql-hackers@postgresql.org>
Subject: Re: Performance improvement for joins where outer side is unique
In-reply-to: 
 <CAKFQuwZKHSR8Hkc+13S-2y_Cg5O105ZvG89Q6ermc_=pzuQq0A@mail.gmail.com>
References: <20150320.121140.148610378.horiguchi.kyotaro@lab.ntt.co.jp>
 <CAPpHfdviphQFjk-gaGZGGxLAyt=YuVdJLnntsxOKnU296s9u-Q@mail.gmail.com>
 <CAKJS1f-=1y0-f5FFV2_r7LtS+CL2Lw-nhJjXB3O_0FmBqnK=3A@mail.gmail.com>
 <27152324.eFKJb4Khb5@dinodell> <8608754a32d1325c2f83ba8b1df71585@xs4all.nl>
 <55DA1F9F.5040204@2ndquadrant.com>
 <CAKJS1f-9UTo6fA+h8rojd30CujSKscZamLn5YnKw5+ASbV0Wwg@mail.gmail.com>
 <5085.1440375543@sss.pgh.pa.us>
 <CAKJS1f_8hrzTDCu0pwERWj_dLZu-6DYFQJAtNT+vM6UeOn0kHw@mail.gmail.com>
 <8907.1440383377@sss.pgh.pa.us>
 <CAKJS1f8JCt15ngEP8sZO-JYYT8mS6HUP_CT0T6S_0ogk1kQt+Q@mail.gmail.com>
 <CAKJS1f_4hm3qwKeHYKftd+BQuYBgdNR+rk+XP_JW9EY-ALHZbQ@mail.gmail.com>
 <56718B15.6060507@2ndquadrant.com>
 <CAKJS1f_i7dGh9ytc0DuaX3JJaN7Gp9AGXNbdtWjj0PkPzNzUeg@mail.gmail.com>
 <5671FF0D.2010403@2ndquadrant.com>
 <CANP8+j+vxfEf3dqhnzKAnDopnnUM-Zjb90gNT=haEQNQePj9Mw@mail.gmail.com>
 <CAKJS1f8MpcL4_oS+n-vmnisd_8OMuZR2vyLETOF7ABSLk_iNZg@mail.gmail.com>
 <56A25A72.2090505@2ndquadrant.com> <24304.145748278!
 0@sss.pgh.pa.us>
 <CAKJS1f-qN8NVT456XT6-NW+Vc_n0-jfCVtaQio0JoOWzP6F2ig@mail.gmail.com>
 <13653.1457731978@sss.pgh.pa.us> <16023.1457736190@sss.pgh.pa.us>
 <CAKJS1f_jRki1PQ4X-9UGKa-wnBhECQLnrxCX5haQzu4SDR_r2Q@mail.gmail.com>
 <CAKFQuwZKHSR8Hkc+13S-2y_Cg5O105ZvG89Q6ermc_=pzuQq0A@mail.gmail.com>
Comments: In-reply-to "David G. Johnston" <david.g.johnston@gmail.com>
	message dated "Sat, 12 Mar 2016 07:44:20 -0700"
Date: Sat, 12 Mar 2016 10:51:39 -0500
Message-ID: <13157.1457797899@sss.pgh.pa.us>
X-Pg-Spam-Score: -1.9 (-)
List-Archive: <http://archives.postgresql.org/pgsql-hackers>
List-Help: <mailto:majordomo@postgresql.org?body=help>
List-ID: <pgsql-hackers.postgresql.org>
List-Owner: <mailto:pgsql-hackers-owner@postgresql.org>
List-Post: <mailto:pgsql-hackers@postgresql.org>
List-Subscribe: <mailto:majordomo@postgresql.org?body=sub%20pgsql-hackers>
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-hackers>
X-Mailing-List: pgsql-hackers
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org

"David G. Johnston" <david.g.johnston@gmail.com> writes:
> Don't the semantics of a SEMI JOIN also state that the output columns only
> come from the outer relation? i.e., the inner relation doesn't contribute
> either rows or columns to the final result?  Or is that simply
> an implementation artifact of the fact that the only current way to perform
> a semi-join explicitly is via exists/in?

I think it's an artifact.  What nodes.h actually says about it is you get
the values of one randomly-selected matching inner row, which seems like
a fine definition for the purposes we plan to put it to.

			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