2cdc3d69da
Some checks failed
Backend tests / test (push) Has been cancelled
Trzy zmiany wokol listy scen z filtrem originu, gdzie kandydatow sa dziesiatki tysiecy. 1. Kolejnosc czlonow OR w stub_exclusion_clause. Postgres liczy OR po kolei i przerywa na pierwszym trafieniu, a sam czlonow nie przestawia. "Ma kanon" (jedyny czlon z JOIN-em do sources) stal przed tanszym "ma performera", wiec placilismy za niego takze za sceny, ktore performera mialy. Po zamianie ten czlon liczy sie 5146 razy zamiast 16 191. 2. Indeks scene_external_refs (scene_id, source_id), migracja 0041. Podzapytanie "ma kanon" dociagalo source_id z heapu, bo stary indeks zna tylko scene_id. Teraz idzie Index Only Scanem: Heap Fetches 16 191 -> 1241. Razem: sort=title + origin=hqporner, strona 5 czyta 251 tys. blokow zamiast 294 tys., a na rozgrzanym cache trwa 305 ms zamiast 371 ms (mediana z 3 rund z rotowana kolejnoscia). Zysk jest skromny. Pierwsze wykonanie na zimnym cache trwa 3-5 s i tak zostaje, bo trzeba dotknac ~2 GB; sprawdzilem tez wariant z materializacja scen originu i CTE, czyta wiecej blokow (302 tys.), wiec obecny plan zostaje. 3. has_playback=false RAZEM z filtrem originu to warunek sprzeczny, bo origin wymaga zrodla z dead_at IS NULL. Wynik jest pusty z definicji, ale Postgres przemielal caly katalog, zeby to stwierdzic: 148 s. Teraz zwarte na false(), 4,8 ms, dalej zero wynikow. Przy has_playback=true z originem pomijamy z kolei nadmiarowe EXISTS o zywym playbacku, bo origin sam go wymaga, a kosztowalo sonde na kazdym kandydacie. Wyniki bez zmian: strony 1-5 dla origin=hqporner i dla glownego feedu porownane pozycja po pozycji ze stara wersja daja zero roznic, a sam predykat stub zgadza sie na probce 200 tys. scen. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|---|---|---|
| .. | ||
| init | ||
| versions | ||
| env.py | ||
| script.py.mako | ||