- Shipped
- September 23, 2026 at 12:33 PM UTC
- Author
- Kamo
- Commit
- 6add2f1
pg_stat_statements put the public changelog's single-entry reads at the top of the database by a distance: the slug lookup and the two neighbour lookups ran ~905K times each at ~245 ms — together about 70% of all the time YugabyteDB spent executing statements. The marketing site renders every entry page per request (~19K entries x 22 locales), so crawlers keep them busy, and each view cost three near-full reads of commit_logs: - findBySlug used `commitHash LIKE :prefix AND project IN (...)`. The unique index on commit_hash is HASH-sharded, so no prefix scan was ever possible (the comment claiming otherwise is gone), and with the project list present the planner walked (project, date_committed) and filtered every public row. It is now the half-open range [prefix, prefix + "~") — every hex character sorts below '~' in the C collation — over the new ix_commit_logs_hash_prefix, with the public-project filter applied in Java to at most 16 candidates. Same answer: exactly one public match or nothing. - newer/older compared `(d > :d OR (d = :d AND id > :id))`, which gives no index a place to start. They now say `d >= :d AND (d > :d OR id > :id)` (equivalent), so ix_commit_logs_date_uid starts its walk at the entry. Measured on production with forced generic plans (what JDBC's server-side prepares get): slug 2.2 ms (was ~245-316), newer 1.3 ms and older 1.2 ms (was ~190). The two indexes were created by hand as the owner and are recorded in **************** PublicChangelogLookupTest pins the statement shapes and the Java-side filter (4 of 5 red against the previous service).