public inbox for [email protected]
help / color / mirror / Atom feedFrom: Tom Lane <[email protected]>
To: Mark Kirkwood <[email protected]>
Cc: David Rowley <[email protected]>
Cc: [email protected]
Subject: Re: Unexpected planner choice in simple JOIN
Date: Wed, 07 Jan 2026 23:51:53 -0500
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>
References: <[email protected]>
<[email protected]>
<CAApHDvqLR27kZkK5zaK2-6LQo_RB_wnVg8DHfHj17cTbr+RHtQ@mail.gmail.com>
<[email protected]>
<CAApHDvoGwHEx1cFQyy-p_ExDMbkYZQFxE4h0qt1ubkd=CHrioA@mail.gmail.com>
<[email protected]>
<[email protected]>
<[email protected]>
Mark Kirkwood <[email protected]> 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
view thread (10+ messages) latest in thread
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected], [email protected]
Subject: Re: Unexpected planner choice in simple JOIN
In-Reply-To: <[email protected]>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox