pf_app
Paul Trowbridge
812678bb7f
Pointing completion at the source made every keystroke a 76-second query: gs.osm_skinny is a plain view over rlarp.osm_stack, so ILIKE '%1601%' scanned 6.9M rows and read 1.3M buffers off disk, 64s of it I/O. Nothing had called that endpoint before, so the cost only appeared once a debounced input was wired to it. The source is the wrong list anyway. It reaches back over all of history and would offer parts discontinued years ago; the version holds what was actually loaded, which is what the forecast is being written against. So GET /versions/:id/values/:col reads the version's own forecast table -- 2.0s for 11,290 parts on fc_osm_skinny_29 -- and holds the result in memory, keyed on that version's latest pf.log id. Any load, adjustment or undo moves the id and the next request rebuilds, so nothing has to remember to invalidate. Filtering happens over the cached array, so typing costs one small max(id) query. The column name is interpolated into the DISTINCT, so it is checked against col_meta first. The source-side endpoint keeps its new q/limit but no longer has a caller; its ILIKE path against a view is the expensive one and should stay unused. 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 | ||