jasc@gmx.net writes:
> We have a server which reports negative costs in a query plan:
The root of the weirdness seems to be here:
> -> Bitmap Heap Scan on converting_touchpoints_attribution conv
(cost=-2021924572970281.75..-2021924572970244.00rows=1 width=10) (never executed)
> Recheck Cond: ((t.touchpoint_id = touchpoint_fk) AND (performance_attribution_model_fk = 2))
> -> BitmapAnd (cost=-2021924572970281.75..-2021924572970281.75 rows=1850 width=0) (never executed)
> -> Bitmap Index Scan on converting_touchpoints_attribution__touchpoint_fk
(cost=0.00..-2021911688068401.00rows=1850 width=0) (never executed)
> Index Cond: (t.touchpoint_id = touchpoint_fk)
> -> Bitmap Index Scan on converting_touchpoints_attribution__performance_attribution_mod
(cost=0.00..-12884901880.97rows=1850 width=0) (never executed)
> Index Cond: (performance_attribution_model_fk = 2)
I'm not sure what to make of that, but it seems to be broken in more ways
than just the wacko cost estimates. For one thing, the planner is supposed
to set up index qual conditions in the form "indexedvar op something",
and the (t.touchpoint_id = touchpoint_fk) condition appears to be
backwards. The row estimate at the intermediate BitmapAnd node seems
to be out of line as well, why doesn't it match the estimate for the
heapscan node?
Can you get a similarly broken plan if you try something involving just
this table, say "select * from converting_touchpoints_attribution where
touchpoint_fk = 42 and performance_attribution_model_fk = 2" ?
Could we see the pg_stats rows for those two columns? What is in
pg_class.reltuples and relpages for this table and these two indexes?
regards, tom lane