On Sat, 25 Jul 2020 at 10:42, David Rowley <[email protected]> wrote:
>
> On Sat, 25 Jul 2020 at 10:37, Tom Lane <[email protected]> wrote:
> >
> > David Rowley <[email protected]> writes:
> > > However, for now, you might just want to try raising various jit
> > > thresholds so that it only is enabled for more expensive plans.
> >
> > Yeah. I'm fairly convinced that the v12 defaults are far too low,
> > because we are constantly seeing complaints of this sort.
>
> I think plan cost overestimation is a common cause of unwanted jit too.
>
> It would be good to see the EXPLAIN ANALYZE so we knew if that was the
> case here.
So Scott did send me the full EXPLAIN ANALYZE for this privately. He
wishes to keep the full output private.
After looking at it, it seems the portion that he pasted above, aka:
-> Index Scan using equities_rds_id on equities e0 (cost=0.42..33.74
rows=1 width=37) (actual time=6751.892..6751.892 rows=0 loops=1)
Index Cond: (rds_id = ANY ('{..., ..., ..., ...}'::uuid[]))
Filter: (security_type = 'ETP'::text)
Rows Removed by Filter: 4
Is nested at the bottom level join, about 6 joins deep. The lack of
any row being found results in upper level joins not having to do
anything, and the majority of the plan is (never executed).
David
