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.96) (envelope-from ) id 1vdi1Y-003kHK-2C for pgsql-performance@arkaria.postgresql.org; Thu, 08 Jan 2026 04:53:29 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1vdi1X-000DAl-25 for pgsql-performance@arkaria.postgresql.org; Thu, 08 Jan 2026 04:53:28 +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.96) (envelope-from ) id 1vdi04-0008nA-1P for pgsql-performance@lists.postgresql.org; Thu, 08 Jan 2026 04:51:57 +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.96) (envelope-from ) id 1vdi03-004pZn-1B for pgsql-performance@lists.postgresql.org; Thu, 08 Jan 2026 04:51:56 +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 6084prL61896855; Wed, 7 Jan 2026 23:51:53 -0500 From: Tom Lane To: Mark Kirkwood cc: David Rowley , pgsql-performance@lists.postgresql.org Subject: Re: Unexpected planner choice in simple JOIN In-reply-to: <02d73d5c-bfd8-4d88-9c5d-2f298bcffa78@gmail.com> References: <71afdb09-0583-4af2-a3b3-50da4f987b9b@gmail.com> <1895375.1767846864@sss.pgh.pa.us> <02d73d5c-bfd8-4d88-9c5d-2f298bcffa78@gmail.com> Comments: In-reply-to Mark Kirkwood message dated "Thu, 08 Jan 2026 17:44:25 +1300" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <1896853.1767847913.1@sss.pgh.pa.us> Date: Wed, 07 Jan 2026 23:51:53 -0500 Message-ID: <1896854.1767847913@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Mark Kirkwood writes: > A point comes to mind - this is not a particularly unusual setup (i.e > relatively small parent table with big child one), so maybe the defaults > are not ideal here? Very probably. To my mind, the default costs for parallel query and JIT are both unduly optimistic and tend to drive the planner to use those features when you'd be better off without. The reason there's not been more argument about them is that the downside of using those features on a too-small query is bounded, while the upside of using them on very-big queries isn't. So nobody's invested the effort to gather enough evidence to back choosing a different set of defaults. regards, tom lane