perf(crons): Adjust specific environment monitor stats query

[scttcper]

Monitor stats has two query shapes. This optimizes the environment-backed shape, for example requests that include ?environment=... or otherwise resolve to MonitorEnvironment rows before querying check-ins.

In that shape, the endpoint already has a mapping from monitor_environment_id to monitor_id. This leaves monitor_id out of the aggregate so Postgres can answer from the existing (monitor_environment_id, date_added, status) index, then recovers monitor_id from the MonitorEnvironment rows it already loaded.

The no-monitor-environment fallback keeps the old aggregate shape because it has no environment-to-monitor mapping.

The query plan change from an environment-backed stats request:

Shape	Plan	Runtime
aggregate included monitor_id	index scan on the same composite index, with heap reads for monitor_id	about 5.5s
aggregate uses bucket, monitor_environment_id, status	index-only scan on the same composite index, with a small number of heap fetches	about 12.5ms

attempt to fix SENTRY-3VHC

[scttcper]

checking another one via EXPLAIN in redash

Old query shape:
- Plan: Index Scan on `sentry_moni_monitor_1fb26c_idx `
- Rows scanned: 10,479
- Output groups: 1,114
- Buffers: 292 hits, 10,292 reads, 6,521 writes
- Execution time: 5,487 ms

New query shape:
- Plan: Index Only Scan on `sentry_moni_monitor_1fb26c_idx `
- Rows scanned: 10,479
- Output groups: 1,114
- Heap fetches: 160
- Buffers: 4,086 hits, 0 reads
- Execution time: 12.5 ms

[wedamija]

checking another one via EXPLAIN in redash

Old query shape:
- Plan: Index Scan on `sentry_moni_monitor_idx`
- Rows scanned: 10,479
- Output groups: 1,114
- Buffers: 292 hits, 10,292 reads, 6,521 writes
- Execution time: 5,487 ms

New query shape:
- Plan: Index Only Scan on `sentry_moni_monitor_idx`
- Rows scanned: 10,479
- Output groups: 1,114
- Heap fetches: 160
- Buffers: 4,086 hits, 0 reads
- Execution time: 12.5 ms

Did you run these for the same organization? If you ran the new query after the old, postgres might have cached it. To be sure, it'd be helpful to find another candidate and run new and then old to see if it still improves

[wedamija]

sentry_moni_monitor_idx

Is this the name of the actual index in your explains? I don't see it in the production table https://redash.getsentry.net/queries/11098/source. It'd be helpful to know if the actual index usage changed here

[scttcper]

@wedamija i tried running the new one first and old one first on some different queries. i've updated the comment with the actual index used sentry_moni_monitor_1fb26c_idx

[wedamija]

This seems like it should help based on the queries we tested on slack. I'd say try it out, and revert if you don't see the slow queries improve