Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1n9oTe-0001ee-St for pgsql-hackers@arkaria.postgresql.org; Tue, 18 Jan 2022 13:24:47 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1n9oTd-00033j-PK for pgsql-hackers@arkaria.postgresql.org; Tue, 18 Jan 2022 13:24:45 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1n9oTc-00032t-Kr for pgsql-hackers@lists.postgresql.org; Tue, 18 Jan 2022 13:24:45 +0000 Received: from wout1-smtp.messagingengine.com ([64.147.123.24]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1n9oTZ-0002Ei-SK for pgsql-hackers@postgresql.org; Tue, 18 Jan 2022 13:24:43 +0000 Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.west.internal (Postfix) with ESMTP id EDA643201F73; Tue, 18 Jan 2022 08:24:39 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute5.internal (MEProxy); Tue, 18 Jan 2022 08:24:40 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:subject:to :x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm1; bh=Q2s4tllmfM1h1TycwWTZ/+NgkH8bfy5omww2cJq030c=; b=iEBWr9DO MUtDEZlICM3ECLvR7Vlx35tK0idAMaW+Yh68JcRPV8felGCxTgXwOkCBHeceecfo UW2tiSYYCiayd7CrzFxsIElB8mx9Spt05XiYhvaU5Gtss/IXUFL8UfJzfq4LJ0SZ hkgBBXljncN4/OuOLFF0rDPUyZC4fjZqDTSZzXiCJIhclM4hV7IAfnJKHo+nB6G9 YWKIuxM7jzM6I92aUkOhMIhNaUbb/pfWfTweu5txo1CzY5zox5yZh/9B4gUF2vAB 0eZhCZT1K78xX6DeaCP0DUydkbwCAw2K+rfzj98q6ti7ViYyA1P89Y2GvcNqAH59 a/DXMgADkR5Tlw== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvvddrudefgdehtdcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpeffhffvuffkgggtugfgjgesthekredttddtjeenucfhrhhomheptehlvhgrrhho ucfjvghrrhgvrhgruceorghlvhhhvghrrhgvsegrlhhvhhdrnhhoqdhiphdrohhrgheqne cuggftrfgrthhtvghrnhepudejveejffejveduudetvdekieeuiedtvdeileefkeevjedu feeguedvjefhueelnecuffhomhgrihhnpegvnhhtvghrphhrihhsvggusgdrtghomhenuc evlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegrlhhvhhgv rhhrvgesrghlvhhhrdhnohdqihhprdhorhhg X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 18 Jan 2022 08:24:39 -0500 (EST) Received: by perhan.alvh.no-ip.org (Postfix, from userid 1000) id 00F6C2A07D6; Tue, 18 Jan 2022 10:24:34 -0300 (-03) Date: Tue, 18 Jan 2022 10:24:34 -0300 From: Alvaro Herrera To: Julien Rouhaud Cc: Arne Roland , pgsql-hackers Subject: Re: missing indexes in indexlist with partitioned tables Message-ID: <202201181324.idvthmrhbtf5@alvherre.pgsql> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20220118065750.v5zigpuisljc6jmk@jrouhaud> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On 2022-Jan-18, Julien Rouhaud wrote: > SET enable_partitionwise_join = on; > EXPLAIN (COSTS OFF) > SELECT * FROM fract_t x LEFT JOIN fract_t y USING (id) ORDER BY id ASC LIMIT 10; > - QUERY PLAN > ------------------------------------------------------------------------ > + QUERY PLAN > +----------------------------------------------------------------- > Limit > - -> Merge Append > - Sort Key: x.id > - -> Merge Left Join > - Merge Cond: (x_1.id = y_1.id) > - -> Index Only Scan using fract_t0_pkey on fract_t0 x_1 > - -> Index Only Scan using fract_t0_pkey on fract_t0 y_1 > - -> Merge Left Join > - Merge Cond: (x_2.id = y_2.id) > - -> Index Only Scan using fract_t1_pkey on fract_t1 x_2 > - -> Index Only Scan using fract_t1_pkey on fract_t1 y_2 > -(11 rows) > + -> Append > + -> Index Only Scan using fract_t0_pkey on fract_t0 x_1 > + -> Index Only Scan using fract_t1_pkey on fract_t1 x_2 > +(4 rows) Hmm, these plan changes look valid to me. A left self-join using the primary key column? That looks optimizable all right. I suspect that the author of partition-wise joins would want to change these queries so that whatever was being tested by these self-joins is tested by some other means (maybe just create an identical partitioned table via CREATE TABLE fract_t2 ... ; INSERT INTO fract_t2 SELECT FROM fract_t). But at the same time, the author of this patch should a) make sure that the submitted patch updates these test results so that the test pass, and also b) add some test cases to verify that his desired behavior is tested somewhere, not just in a test case that's incidentally broken by his patch. What I still don't know is whether this patch is actually desirable or not. If the only cases it affects is self-joins, is there much actual value? -- Álvaro Herrera Valdivia, Chile — https://www.EnterpriseDB.com/