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 1rGhOF-00GfQU-5v for pgsql-hackers@arkaria.postgresql.org; Fri, 22 Dec 2023 15:24:43 +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 1rGhOD-008K3y-Ns for pgsql-hackers@arkaria.postgresql.org; Fri, 22 Dec 2023 15:24:41 +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 1rGhOD-008K3p-Dy for pgsql-hackers@lists.postgresql.org; Fri, 22 Dec 2023 15:24:41 +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.94.2) (envelope-from ) id 1rGhOA-00DN7B-Pa for pgsql-hackers@postgresql.org; Fri, 22 Dec 2023 15:24:40 +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 3BMFOFcx1052851; Fri, 22 Dec 2023 10:24:21 -0500 From: Tom Lane To: Heikki Linnakangas cc: Xiaoran Wang , pgsql-hackers , Andrew Kane , Matthias van de Meent Subject: Re: Avoid computing ORDER BY junk columns unnecessarily In-reply-to: References: <2ca5865b-4693-40e5-8f78-f3b45d5378fb@iki.fi> Comments: In-reply-to Heikki Linnakangas message dated "Fri, 22 Dec 2023 12:48:53 +0200" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <1052849.1703258655.1@sss.pgh.pa.us> Date: Fri, 22 Dec 2023 10:24:15 -0500 Message-ID: <1052850.1703258655@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Heikki Linnakangas writes: > Hmm, so return the computed column from the index instead of recomputing > it? Yeah, that makes sense too and would help in this example. Yeah, that's been on the to-do list for ages. The main problems are (1) we need the planner to not spend too much effort on looking for subexpression matches, and (2) amcanreturn ability isn't implemented by the executor in plain indexscans. There's another thread right now discussing fixing (2), after which we could perhaps work on this. > It won't > help in all cases though, the index might not store the original value > in the first place. I'm a little skeptical that an index could produce an accurate ORDER BY result if it doesn't store the values-to-be-sorted exactly. Any loss of information would compromise its ability to sort nearly-identical values correctly. A more credible argument is that the index might expose amcanorder ability but not amcanreturn; but what I'm saying is that that's probably an AM implementation gap that ought to be fixed. How much of your patchset still makes sense if we assume that we can always extract the ORDER BY column values from the index? regards, tom lane