Re: Unexpected planner choice in simple JOIN - Mailing list pgsql-performance

From Tom Lane
Subject Re: Unexpected planner choice in simple JOIN
Date
Msg-id 1896854.1767847913@sss.pgh.pa.us
Whole thread Raw
In response to Re: Unexpected planner choice in simple JOIN  (Mark Kirkwood <mark.kirkwood@gmail.com>)
Responses Re: Unexpected planner choice in simple JOIN
List pgsql-performance
Mark Kirkwood <mark.kirkwood@gmail.com> 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



pgsql-performance by date:

Previous
From: Mark Kirkwood
Date:
Subject: Re: Unexpected planner choice in simple JOIN
Next
From: Mark Kirkwood
Date:
Subject: Re: Unexpected planner choice in simple JOIN