4.8 KiB
4.8 KiB
id, title, status, type, team, supporting_teams, roadmap_item, priority
| id | title | status | type | team | supporting_teams | roadmap_item | priority | |
|---|---|---|---|---|---|---|---|---|
| TASK-189-add-ranking-materialized-read-indexes | Add ranking materialized read indexes | done | backend | Arquitecto de Base de Datos |
|
foundation | high |
TASK-189 - Add ranking materialized read indexes
Goal
Add safe indexes on the materialized tables used by Ranking and Stats to reduce scans and improve join performance.
Context
The current Ranking and Stats runtime reads depend on rcon_materialized_matches, rcon_match_player_stats and annual snapshot tables. After TASK-188 documents the real bottlenecks, HLL Vietnam needs a narrow indexing pass that improves read performance without changing API contracts, recalculating rankings or introducing a second architecture.
Preserve the current product identity: Spanish-speaking HLL Vietnam community, military/Vietnam/tactical/sober visual direction and controlled repository evolution.
Steps
- Read the listed files first.
- Use
docs/ranking-stats-performance-audit.mdas the primary justification source. - Add only the indexes supported by the audit findings and the existing storage initialization/migration pattern.
- Keep SQLite/Postgres compatibility if both storage modes are supported in the current backend.
- Re-run the validation scripts and, if possible, compare before/after timing for one or two representative endpoints.
Files to Read First
AGENTS.mdai/repo-context.mdai/architecture-index.mddocs/ranking-stats-performance-audit.mdbackend/app/rcon_admin_log_materialization.pybackend/app/rcon_historical_leaderboards.pybackend/app/rcon_historical_player_stats.pybackend/app/rcon_annual_rankings.pybackend/app/postgres_rcon_storage.pybackend/app/sqlite_utils.py
Expected Files to Modify
backendstorage/migration/init module correspondiente, según patrón existentedocs/ranking-stats-performance-audit.md, solo si se documenta índice aplicadoai/tasks/done/TASK-189-add-ranking-materialized-read-indexes.md
Constraints
- No cambiar contratos API.
- No cambiar frontend.
- No recalcular rankings.
- No crear snapshots en esta task.
- No reactivar Elo/MMR.
- No reintroducir Comunidad Hispana #03.
- Mantener compatibilidad SQLite/Postgres si el proyecto usa ambos.
- Basar los índices en evidencia documentada por
TASK-188, no en suposiciones.
Validation
Before completing the task ensure:
- the chosen indexes are justified by
TASK-188 - candidate coverage explicitly considers:
target_key + match_keysource_basis + ended_at/started_attarget_key + ended_at/started_atplayer_idplayer_nameif search benefits from itsnapshot_id + ranking_positionin snapshot tables if applicable
powershell -ExecutionPolicy Bypass -File scripts/run-stats-validation.ps1powershell -ExecutionPolicy Bypass -File scripts/run-integration-tests.ps1- if possible, before/after timing is captured for one or two endpoints
- any measurement limitations are documented
git diff --name-onlystays within scope
Outcome
- Added SQLite/PostgreSQL-compatible indexes in the materialized storage initialization path:
idx_rcon_materialized_matches_source_window_textidx_rcon_materialized_matches_target_source_window_textidx_rcon_materialized_matches_external_source_window_textidx_rcon_match_player_stats_player_id_match
- Kept existing annual snapshot indexes unchanged because the annual read path was already using matching indexes.
- Did not add a plain
player_nameB-tree because the current search query usesLOWER(player_name) LIKE '%term%'with a leading wildcard, so the audit did not justify it as a useful narrow index. - Post-index validation confirmed plan improvement:
- weekly count queries now use the new
source_basis + windowcovering index - the stats player-detail aggregate now narrows through the match window index and then probes stats by
(target_key, match_key, player_id)
- weekly count queries now use the new
- Before/after timing was captured for representative endpoints:
/api/stats/players/{player_id}weekly improved from8.924 ms / 4.494 ms SQLto4.300 ms / 1.043 ms SQL/api/rankingweeklykillsshowed no meaningful change in this dataset because the active weekly window on2026-06-09is empty
- Validation scripts executed successfully:
powershell -ExecutionPolicy Bypass -File scripts/run-stats-validation.ps1powershell -ExecutionPolicy Bypass -File scripts/run-integration-tests.ps1
- Remaining gap:
- weekly/monthly public ranking still does repeated runtime counting and grouped aggregation per request, so snapshot-backed reads remain necessary in
TASK-190andTASK-191
- weekly/monthly public ranking still does repeated runtime counting and grouped aggregation per request, so snapshot-backed reads remain necessary in
Change Budget
- Prefer fewer than 5 modified files.
- Prefer changes under 200 lines when feasible.
- Split the work into follow-up tasks if limits are exceeded.