Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.84) (envelope-from ) id 1aeVm9-0004dG-Qf for pgsql-hackers@arkaria.postgresql.org; Fri, 11 Mar 2016 22:43:17 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.84) (envelope-from ) id 1aeVm9-0000r7-2t for pgsql-hackers@arkaria.postgresql.org; Fri, 11 Mar 2016 22:43:17 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84) (envelope-from ) id 1aeVm8-0000r0-EB for pgsql-hackers@postgresql.org; Fri, 11 Mar 2016 22:43:16 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84) (envelope-from ) id 1aeVm5-0004kP-KE for pgsql-hackers@postgresql.org; Fri, 11 Mar 2016 22:43:16 +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 u2BMhAIg016024; Fri, 11 Mar 2016 17:43:10 -0500 From: Tom Lane To: David Rowley cc: Tomas Vondra , Simon Riggs , PostgreSQL-development Subject: Re: Performance improvement for joins where outer side is unique In-reply-to: <13653.1457731978@sss.pgh.pa.us> References: <20150320.121140.148610378.horiguchi.kyotaro@lab.ntt.co.jp> <27152324.eFKJb4Khb5@dinodell> <8608754a32d1325c2f83ba8b1df71585@xs4all.nl> <55DA1F9F.5040204@2ndquadrant.com> <5085.1440375543@sss.pgh.pa.us> <8907.1440383377@sss.pgh.pa.us> <56718B15.6060507@2ndquadrant.com> <5671FF0D.2010403@2ndquadrant.com> <56A25A72.2090505@2ndquadrant.com> <24304.1457482780@sss.pgh.pa.us> <13653.1457731978@sss.pgh.pa.us> Comments: In-reply-to Tom Lane message dated "Fri, 11 Mar 2016 16:32:58 -0500" Date: Fri, 11 Mar 2016 17:43:10 -0500 Message-ID: <16023.1457736190@sss.pgh.pa.us> X-Pg-Spam-Score: -1.9 (-) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-hackers Precedence: bulk Sender: pgsql-hackers-owner@postgresql.org I wrote: > I wondered why, instead of inventing an extra semantics-modifying flag, > we couldn't just change the jointype to *be* JOIN_SEMI when we've > discovered that the inner side is unique. BTW, to clarify: I'm not imagining that we'd make this change in the query jointree, as for example prepjointree.c might do. That would appear to add join order constraints, which we don't want. But I'm thinking that at the instant where we form a join Path, we could change the Path's jointype to be JOIN_SEMI or JOIN_SEMI_OUTER if we're able to prove the inner side unique, rather than annotating the Path with a separate flag. Then that representation is what propagates forward. It seems like the major intellectual complexity here is to figure out how to detect inner-side-unique at reasonable cost. I see that for LEFT joins you're caching that in the SpecialJoinInfos, which is probably fine. But for INNER joins it looks like you're just doing it over again for every candidate join, and that seems mighty expensive. 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