On Mon, Aug 23, 2021 at 08:53:15PM -0400, Matt Dupree wrote:
> Is it possible that the row estimate is off because of a column other than
> time?
I would test this by writing the simplest query that reproduces the
mis-estimate.
> I looked at the # of events in that time period and 1.8 million is
> actually a good estimate. What about the
> ((strpos(other_events_1004175222.hierarchy, '#close_onborading;'::text) <>
> 0) condition in the filter? It makes sense that Postgres wouldn't have a
> way to estimate how selective this condition is.
The issue I see is here. I don't know where else I'd start but to understand
this.
| Index Scan using other_events_1004175222_pim_evdef_67951aef14bc_idx on public.other_events_1004175222
(cost=0.28..1,648,877.92ROWS=1,858,891 width=32) (actual time=1.008..15.245 ROWS=23 loops=1)
| Output: other_events_1004175222.user_id, other_events_1004175222."time", other_events_1004175222.session_id
| Index Cond: ((other_events_1004175222."time" >= '1624777200000'::bigint) AND (other_events_1004175222."time" <=
'1627369200000'::bigint))
| Buffers: shared read=25
This has no "filter" condition, it's a "scan" node with bad over-estimate.
Note that this is due to the table's column stats, not any index's stats, so
every plan is affected. even though some happen to work well. The consequences
of over-estimates are not as terrible as for under-estimates, but it's bad to
start with inputs that are off by 10^5.
--
Justin