Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1h9wJf-0007xW-Mv for pgsql-hackers@arkaria.postgresql.org; Fri, 29 Mar 2019 18:33:23 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1h9wJd-0003UP-Tj for pgsql-hackers@arkaria.postgresql.org; Fri, 29 Mar 2019 18:33:21 +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_SHA1:256) (Exim 4.89) (envelope-from ) id 1h9wJd-0003UI-LP for pgsql-hackers@lists.postgresql.org; Fri, 29 Mar 2019 18:33:21 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1h9wJX-0006ko-0J for pgsql-hackers@postgresql.org; Fri, 29 Mar 2019 18:33:21 +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 x2TIWvgX008306; Fri, 29 Mar 2019 14:32:58 -0400 From: Tom Lane To: Amit Langote cc: David Rowley , Imai Yoshikazu , "jesper.pedersen@redhat.com" , "Imai, Yoshikazu" , Amit Langote , Alvaro Herrera , Robert Haas , Justin Pryzby , Pg Hackers Subject: Re: speeding up planning with partitions In-reply-to: <5c83dbca-12b5-1acf-0e85-58299e464a26@lab.ntt.co.jp> References: <0F97FA9ABBDBE54F91744A9B37151A512B45CD@g01jpexmbkw24> <53a80692-c68d-5e11-1014-6441b6e8ca5a@redhat.com> <20519.1553288822@sss.pgh.pa.us> <15573.1553639191@sss.pgh.pa.us> <47d2fd82-3f70-077b-abc6-863e3fa23503@lab.ntt.co.jp> <379243a6-33d5-af38-43c9-37120a0893bd@lab.ntt.co.jp> <18712.1553698656@sss.pgh.pa.us> <5! 9737210-61bd-e583-4393-cc0a5ab52549@lab.ntt.co.jp> <19663.1553749401@sss.pgh.pa.us> <2a531b7c-8ced-f868-2e! f2-5cf33b92ef0f@lab.ntt.co.jp> <23856.1553812684@sss.pgh.pa.us> <5c83dbca-12b5-1acf-0e85-58299e464a26@lab.! ntt.co.jp> Comments: In-reply-to Amit Langote message dated "Fri, 29 Mar 2019 12:44:44 +0900" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <8304.1553884377.1@sss.pgh.pa.us> Date: Fri, 29 Mar 2019 14:32:57 -0400 Message-ID: <8305.1553884377@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk Amit Langote writes: > On 2019/03/29 7:38, Tom Lane wrote: >> 2. I seriously dislike what's been done in joinrels.c, too. That >> really seems like a kluge (and I haven't had time to study it >> closely). > Those hunks account for the fact that pruned partitions, for which we no > longer create RangeTblEntry and RelOptInfo, may appear on the nullable > side of an outer join. We'll need a RelOptInfo holding a dummy path, so > that outer join paths can be created with one side of join being dummy > result path, which are built in the patch by build_dummy_partition_rel(). Just for the record, that code is completely broken: it falls over badly under GEQO. (Try running the regression tests with "alter system set geqo_threshold to 2".) However, the partitionwise join code was completely broken for GEQO before this patch, too, so I'm just going to log that as an open issue for the moment. regards, tom lane