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 1gje86-0003xo-Vl for pgsql-hackers@arkaria.postgresql.org; Wed, 16 Jan 2019 05:52:47 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1gje85-0002N7-IE for pgsql-hackers@arkaria.postgresql.org; Wed, 16 Jan 2019 05:52:45 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1gje85-0002Mz-7v for pgsql-hackers@lists.postgresql.org; Wed, 16 Jan 2019 05:52:45 +0000 Received: from tama500.ecl.ntt.co.jp ([129.60.39.148]) by makus.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1gje82-0000Fp-JP for pgsql-hackers@postgresql.org; Wed, 16 Jan 2019 05:52:43 +0000 Received: from vc1.ecl.ntt.co.jp (vc1.ecl.ntt.co.jp [129.60.86.153]) by tama500.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id x0G5qdAH017522; Wed, 16 Jan 2019 14:52:39 +0900 Received: from vc1.ecl.ntt.co.jp (localhost [127.0.0.1]) by vc1.ecl.ntt.co.jp (Postfix) with ESMTP id 7D95CEA7CE2; Wed, 16 Jan 2019 14:52:39 +0900 (JST) Received: from jcms-pop21.ecl.ntt.co.jp (jcms-pop21.ecl.ntt.co.jp [129.60.87.134]) by vc1.ecl.ntt.co.jp (Postfix) with ESMTP id 72DDAEA7D2C; Wed, 16 Jan 2019 14:52:39 +0900 (JST) Received: from [IPv6:::1] (unknown [129.60.241.75]) by jcms-pop21.ecl.ntt.co.jp (Postfix) with ESMTPSA id 6BBD94003EB; Wed, 16 Jan 2019 14:52:39 +0900 (JST) Message-ID: <5C3EC68F.8030202@lab.ntt.co.jp> Date: Wed, 16 Jan 2019 14:52:15 +0900 From: Etsuro Fujita User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 Subject: Re: Query with high planning time at version 11.1 compared versions 10.5 and 11.0 References: <8db4eca8-6e76-70ff-f934-e0228a1cc298@lab.ntt.co.jp> <20181206075726.pig32e6thltb56hr@alvherre.pgsql> <5C34846E.9090600@lab.ntt.co.jp> <96720c99-ffa0-01ad-c594-0504c8eda708@lab.ntt.co.jp> <5C35D912.8040200@lab.ntt.co.jp> <7354b5bf-5932-4c0c-81ee-d9550de18995@lab.ntt.co.jp> <5C36E105.2020902@lab.ntt.co.jp> <5C38910B.8010901@lab.ntt.co.jp> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-CC-Mail-RelayStamp: 1 To: Ashutosh Bapat Cc: Amit Langote , Alvaro Herrera , pryzby@telsasoft.com, sanyo.moura@tatic.net, Jeff Janes , david.rowley@2ndquadrant.com, Robert Haas , pgsql-hackers X-TM-AS-MML: disable List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk Hi Ashutosh, (2019/01/15 13:29), Ashutosh Bapat wrote: > I think, there's something better possible. Two partitioned relations > won't use partition-wise join, if their partition schemes do not match. > Partitioned relations with same partitioning scheme share > PartitionScheme pointer. PartitionScheme structure should get an extra > counter, maintaining a count of number of partitioned relations sharing > that structure. When this counter is 1, that relation is certainly not > going to participate in PWJ and thus need not have all the structure > required by PWJ set up. If we use this counter coupled with > enable_partitionwise_join flag, we can get rid of > consider_partitionwise_join flag altogether, I think. Interesting! That flag was introduced to disable PWJs when whole-row Vars are involved, as you know, so I think we need to first eliminate that limitation, to remove that flag. Thanks! Best regards, Etsuro Fujita