Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1tVjwX-00B0bd-FG for pgsql-bugs@arkaria.postgresql.org; Thu, 09 Jan 2025 04:14:49 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1tVjwW-00BYwb-GL for pgsql-bugs@arkaria.postgresql.org; Thu, 09 Jan 2025 04:14:48 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1tVjwW-00BYwQ-7f for pgsql-bugs@lists.postgresql.org; Thu, 09 Jan 2025 04:14:47 +0000 Received: from sss.pgh.pa.us ([68.162.161.243]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1tVjwT-000fHD-07 for pgsql-bugs@lists.postgresql.org; Thu, 09 Jan 2025 04:14:47 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.15.2/8.15.2) with ESMTP id 5094EcKE1795557; Wed, 8 Jan 2025 23:14:38 -0500 From: Tom Lane To: David Rowley cc: dqetool@126.com, pgsql-bugs@lists.postgresql.org Subject: Re: BUG #18764: server closed the connection unexpectedly In-reply-to: References: <18764-63ad667ea26e877a@postgresql.org> <446342.1735923417@sss.pgh.pa.us> <468120.1735927103@sss.pgh.pa.us> Comments: In-reply-to David Rowley message dated "Thu, 09 Jan 2025 16:30:43 +1300" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <1795555.1736396078.1@sss.pgh.pa.us> Date: Wed, 08 Jan 2025 23:14:38 -0500 Message-ID: <1795556.1736396078@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk David Rowley writes: > On Sat, 4 Jan 2025 at 06:58, Tom Lane wrote: >> There is no value in forcing a sort of the subquery's output, >> and the previous code didn't do so: > The reason for the 2nd sort, (ignoring the invalidity of the pathkeys) > is due to how build_setop_child_paths() tries sorting the > cheapest_input_path. The problem is that the sorted path gets added > to the same RelOptInfo as the cheapest_input_path so if add_path() > sees they're fuzzily the same cost, the sorted has better pathkeys, so > the actual cheapest path is thrown away. I think the reason this > happens in this case is that there are just not that many rows to > sort, and it's fairly expensive to get those rows. Yeah, same conclusion Richard and I came to. It's not that big a problem (aside from the validity issue) because this path would only win if the sorting cost is estimated to be insignificant relative to the subquery's other costs. So while it might be nice to improve that in future, I'm not very concerned about it now. regards, tom lane