"""Indeksy czesciowe pod progi filtra jakosci (720/1080/2160)

Dlaczego osobne indeksy na prog, a nie jeden na (max_quality_p, created_at):
tamten nie da sie uzyc do `ORDER BY created_at DESC LIMIT n`, bo wynik nie jest
posortowany po created_at w obrebie ZAKRESU wartosci max_quality_p. Planer go
ignorowal i wracal do przejscia `scenes` po dacie z filtrem.

Indeks czesciowy z predykatem `max_quality_p >= N`, posortowany po created_at DESC,
jest dla progu N dokladnie tym, czego zapytanie potrzebuje: Postgres uzywa go, gdy
warunek zapytania implikuje predykat indeksu. Zmierzone na produkcji 2026-08-18:

    0029 (sama kolumna)   2,0-2,6 s   planer szedl ix_scenes_created_at_desc
    0030 (te indeksy)     0,09-0,11 s Index Scan using ix_scenes_created_q1080

Progi sa ZWIAZANE Z UI: `QUALITY_OPTIONS` w mobile/src/screens/ScenesFilterModal.tsx
oferuje dokladnie 720/1080/2160. Inna wartosc w `?min_quality_p=` nadal dziala, tylko
wolniej (fallback do skanu po dacie). Dodajac opcje w UI, dodaj tu indeks.

Rozmiary sa pomijalne (4,3 MB / 2,7 MB / 0,3 MB), bo jakosc zna tylko 6,5% katalogu.

Revision ID: 0030_scenes_quality_idx
Revises: 0029_scenes_max_quality
Create Date: 2026-08-18
"""
from __future__ import annotations

import sqlalchemy as sa
from alembic import op

revision: str = "0030_scenes_quality_idx"
down_revision: str | None = "0029_scenes_max_quality"
branch_labels = None
depends_on = None

_THRESHOLDS = (720, 1080, 2160)


def upgrade() -> None:
    for q in _THRESHOLDS:
        op.create_index(
            f"ix_scenes_created_q{q}",
            "scenes",
            [sa.text("created_at DESC")],
            postgresql_where=sa.text(f"max_quality_p >= {q}"),
        )


def downgrade() -> None:
    for q in _THRESHOLDS:
        op.drop_index(f"ix_scenes_created_q{q}", table_name="scenes")