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 1sj2bQ-00DKD1-49 for pgsql-hackers@arkaria.postgresql.org; Tue, 27 Aug 2024 20:15:44 +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 1sj2bO-00CIG3-1S for pgsql-hackers@arkaria.postgresql.org; Tue, 27 Aug 2024 20:15:42 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1sj2bN-00CIFv-Jl for pgsql-hackers@lists.postgresql.org; Tue, 27 Aug 2024 20:15:42 +0000 Received: from sss.pgh.pa.us ([68.162.161.243]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1sj2bL-001jlR-L9 for pgsql-hackers@postgresql.org; Tue, 27 Aug 2024 20:15: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 47RKFZDe3131958; Tue, 27 Aug 2024 16:15:35 -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> <3118814.1724783090@sss.pgh.pa.us> Comments: In-reply-to Robert Haas message dated "Tue, 27 Aug 2024 15:11:15 -0400" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <3131956.1724789735.1@sss.pgh.pa.us> Date: Tue, 27 Aug 2024 16:15:35 -0400 Message-ID: <3131957.1724789735@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Robert Haas writes: > I believe the minimum viable product here > is probably something like: > - control over scan methods > - control over index selection > - control over join methods > - control over join order Seems reasonable. It might be possible to say that our answer to "control over join order" is to provide a hook that can modify the "joinlist" before it's passed to make_one_rel. If you want to force a particular join order you can rearrange that list-of-lists-of-range-table-indexes to do so. The thing this would not give you is control over which rel is picked as outer in any given join step. Not sure how critical that bit is. regards, tom lane