Tag-filtered scene lists (e.g. blowjob + has_playback) took 4-12s. Root cause: the filter joined scene_tags->tags on slug, so the actual tag_id was opaque to the planner at plan time. It fell back to average per-tag cardinality (8.4M/11541 ≈ 726) instead of the real 273k, chose to materialize ALL matching scene_tags + check playback per row, then top-N sort. Fix: resolve slug->tag_id in the app and filter on a LITERAL tag_id (no slug join). With a constant, the planner uses MCV stats, knows the tag is huge, and walks ix_scenes_created_at_desc probing scene_tags/playback per scene, stopping at the page limit. Verified: blowjob list 3300ms -> 18ms (EXPLAIN), HTTP 4-12s -> 47ms. Unknown slug short-circuits to empty. (Pairs with the raised tag_id statistics target so mid-tier tags also get correct estimates.) Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> |
||
|---|---|---|
| .. | ||
| api | ||
| connectors | ||
| extractors | ||
| models | ||
| normalize | ||
| resolve | ||
| scheduler | ||
| templates | ||
| __init__.py | ||
| auth.py | ||
| config.py | ||
| db.py | ||
| ingest.py | ||
| main.py | ||