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 1tnt9f-003GEz-FT for pgsql-hackers@arkaria.postgresql.org; Fri, 28 Feb 2025 05:43:24 +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 1tnt9f-00EliA-JQ for pgsql-hackers@arkaria.postgresql.org; Fri, 28 Feb 2025 05:43:22 +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 1tnt9f-00Eli1-9x for pgsql-hackers@lists.postgresql.org; Fri, 28 Feb 2025 05:43:21 +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 1tnt9a-0007GW-0M for pgsql-hackers@postgresql.org; Fri, 28 Feb 2025 05:43:21 +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 51S5hH172681346; Fri, 28 Feb 2025 00:43:17 -0500 From: Tom Lane To: Alexandra Wang cc: PostgreSQL Hackers Subject: Re: Remove extra Sort node above a btree-compatible Index Scan In-reply-to: References: Comments: In-reply-to Alexandra Wang message dated "Thu, 27 Feb 2025 23:22:21 -0600" MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-ID: <2681344.1740721397.1@sss.pgh.pa.us> Content-Transfer-Encoding: 8bit Date: Fri, 28 Feb 2025 00:43:17 -0500 Message-ID: <2681345.1740721397@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Alexandra Wang writes: > I’ve attached a patch that removes this unnecessary Sort node for > B-tree-compatible indexes. This does not look right at all. You can't just ignore the opfamily etc. while deciding whether two pathkeys represent the same sort ordering, as you did in create_mergejoin_plan(). I don't like pathkeys_have_same_sortop() either. The pathkey data structures were designed to let pointer comparison be sufficient for deciding whether pathkeys are equivalent: see the "canonical pathkey" stuff in pathkeys.c. I think that this patch may be band-aiding over some breakage of that concept, but you've not provided enough context to figure out what the underlying problem is. regards, tom lane