pf_app
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> |
||
|---|---|---|
| lib | ||
| public | ||
| routes | ||
| setup_sql | ||
| ui | ||
| .env.example | ||
| .gitignore | ||
| CLAUDE.md | ||
| install.sh | ||
| package-lock.json | ||
| package.json | ||
| PERSPECTIVE.md | ||
| pf_perspective_options.md | ||
| pf_spec.md | ||
| pf.sh | ||
| server.js | ||