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 1szhYo-007Xhn-5P for pgsql-bugs@arkaria.postgresql.org; Sat, 12 Oct 2024 19:13:54 +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 1szhYm-008r98-Ad for pgsql-bugs@arkaria.postgresql.org; Sat, 12 Oct 2024 19:13:52 +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 1szhYm-008r8x-1C for pgsql-bugs@lists.postgresql.org; Sat, 12 Oct 2024 19:13:52 +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 1szhYj-000iU9-5f for pgsql-bugs@lists.postgresql.org; Sat, 12 Oct 2024 19:13:51 +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 49CJDlpS3322032; Sat, 12 Oct 2024 15:13:47 -0400 From: Tom Lane To: Andrei Lepikhov cc: Richard Guo , exclusion@gmail.com, pgsql-bugs@lists.postgresql.org Subject: Re: BUG #18652: Planner can not find pathkey item to sort for query with expression and expression index In-reply-to: <73d3a8bb-531d-4db3-be75-e9ba7001a3f3@gmail.com> References: <18652-deaa782ebcca85d1@postgresql.org> <2527690.1728510183@sss.pgh.pa.us> <40c8a5c2-0040-4fe6-ab11-6dca23353a07@gmail.com> <3001952.1728680364@sss.pgh.pa.us> <73d3a8bb-531d-4db3-be75-e9ba7001a3f3@gmail.com> Comments: In-reply-to Andrei Lepikhov message dated "Sat, 12 Oct 2024 13:05:25 +0700" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <3322030.1728760427.1@sss.pgh.pa.us> Date: Sat, 12 Oct 2024 15:13:47 -0400 Message-ID: <3322031.1728760427@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Andrei Lepikhov writes: > On 12/10/2024 03:59, Tom Lane wrote: >> I wonder whether we're doing more work here than we really need to. >> If the underlying table t1 has columns i and j, and we have an EC >> member that references t1.j while the tlist only mentions t1.i, >> wouldn't it still work to add t1.j to the tlist? So maybe groveling >> through the tlist members is unnecessary and we only need to be >> performing some kind of relation-level check on whether all the >> required relations are included in the input. > I'm not sure I understand this point. Do you mean something like > attached? More or less, yeah, although passing the tlist rather than some more-direct representation of the current relation's relids looks weird once you think of it this way. After thinking about this for awhile though, I suspect it is only sure to work for appendrel children (where an EC match should be guaranteed to exist, by construction). Maybe we could use this simplified approach if we know we're considering an appendrel child, but I doubt it's worth having two code paths. regards, tom lane