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 1sj0uL-00CjQV-Il for pgsql-hackers@arkaria.postgresql.org; Tue, 27 Aug 2024 18:27:09 +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 1sj0uJ-00B477-LE for pgsql-hackers@arkaria.postgresql.org; Tue, 27 Aug 2024 18:27:08 +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 1sj0sB-00B0AB-Ra for pgsql-hackers@lists.postgresql.org; Tue, 27 Aug 2024 18:24:56 +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 1sj0s8-001nSs-Ot for pgsql-hackers@postgresql.org; Tue, 27 Aug 2024 18:24:55 +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 47RIOoJ93118815; Tue, 27 Aug 2024 14:24:50 -0400 From: Tom Lane To: Robert Haas cc: "pgsql-hackers@postgresql.org" Subject: Re: allowing extensions to control planner behavior In-reply-to: References: <2909615.1724693854@sss.pgh.pa.us> <3109294.1724777769@sss.pgh.pa.us> Comments: In-reply-to Robert Haas message dated "Tue, 27 Aug 2024 13:17:48 -0400" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <3118813.1724783090.1@sss.pgh.pa.us> Date: Tue, 27 Aug 2024 14:24:50 -0400 Message-ID: <3118814.1724783090@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Robert Haas writes: > Well, now I'm confused. Just yesterday, in response to the 0001 patch > that allows extensions to exert control over the join strategy, you > complained that "Or, if your problem is that the planner wants to scan > index A but you want it to scan index B, enable_indexscan won't help." I was just using that to illustrate that making the enable_XXX GUCs relation-local covers only a small part of the planner-control problem. You had not, at that point, been very clear that you intended that patch as only a small part of a solution. I do think that index selection is pretty well under control already, thanks to stuff that we put in ages ago at the urging of people who wanted to write "index advisor" extensions. (The fact that that area seems a bit moribund is disheartening, though. Is it a lack of documentation?) regards, tom lane