- Shipped
- September 23, 2026 at 2:40 PM UTC
- Author
- Kamo
- Commit
- 1f715e4
DDL: **************** (column + partial-friendly index, applied to production already) and **************** (one-time catch-up, already run — 19,373 rows, all landed on their real count). **************** now keeps commit_logs.translation_count exactly equal to COUNT(*) FROM commit_log_translations for that row, in the same REQUIRES_NEW transaction as each locale write: +1 for a genuinely new locale, unchanged for a re-save of one already there (a retry or a sanitization-rule re-trigger deletes-then-reinserts the same locale — net zero). Wrapped in @RetryOnDbConflict, matching this codebase's convention for a write that a rare concurrent-overlap (the initial post-commit translation still in flight when the 5-minute retry sweep also picks up the same still-incomplete row) could 40001. **************** reads that counter with a plain indexed WHERE **************** instead of the GROUP BY .. HAVING over commit_logs LEFT JOIN commit_log_translations it ran every 5 minutes — measured in production: ~14K calls at ~750ms (a full scan of the ~406K-row translations table), verified via EXPLAIN ANALYZE before wiring this in: 751ms -> 19.6ms (Index Only Scan, Heap Fetches: 0) for the same empty-result case. A correlated per-row subquery rewrite was tried first and rejected: EXPLAIN ANALYZE on production showed it at 13.9s, ~18x WORSE than the original — YugabyteDB's per-RPC cost for many small correlated lookups dominates, which is why this is a maintained column, not a smarter join.