Paul Trowbridge
5376c25e04
Filtering the loads out in the dialog left the server still joining the whole forecast table for them and discarding the answer. ?kind=adjustments moves the filter into the WHERE, so they never enter the join: on version 29 the join goes from 2,556,821 rows to 25, and the query from 1666ms to 719ms. Still 719ms, because nothing indexes pf_logid and it stays a sequential scan of 2.5M rows. New forecast tables now get an index on it. That column is how every entry-level operation finds its rows -- undo deletes by it, this aggregate groups by it, and it is part of the grain key -- so the scan was being paid on all of them. Existing tables predate the index and still scan; fc_osm_skinny_29 would want it added by hand. The route keeps returning everything by default: Baseline.jsx lists the segments from the same endpoint, and the ledger's tag lookup needs every entry to label its lines. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|---|---|---|
| .. | ||
| auth.js | ||
| log.js | ||
| operations.js | ||
| sources.js | ||
| tables.js | ||
| versions.js | ||