0 Releases 4,167 Tags

RSS Feed

• v4.5.7 e9ac98b7a1

  Compare

  perf(run-store): route id-set reads to the owning store, not both DBs (#4342)

  frostbyte_neo released this 2026-07-22 22:03:24 +00:00 | 270 commits to main since this release

  Summary

  The split run-store's id-set read path (#findRunsByIdSet, used by the
  runs-list hydrate, the realtime hydrator, and engine sweeps) queried the
  new store for the entire id set and then probed the legacy store for the
  misses. A run's residency is a total function of its id (run-ops ids
  live in the new store, every other id in legacy), so each id belongs to
  exactly one store. Route each id to its owner and query each store only
  for its own ids, in parallel. Same result set, and while a split is
  active with most runs still on legacy it removes a wasted new-store
  query from every id-set read.

  Change

  #findRunsByIdSet now partitions the ids by classifyResidency and
  runs one bounded query per store (skipping an empty side), in parallel,
  mirroring expireRunsBatch and the single-run #route. finalizeRows
  still applies orderBy/take/skip globally over the merged set.

  This drops the id-set path's cross-store fallback, which existed to
  prefer the new-store copy when the same id was present in both stores.
  That collision cannot arise when each id maps to exactly one store
  (nothing writes a legacy-shaped id into the new store), so the fallback
  is dead code. The two id-set tests that asserted "new copy wins on
  collision" now assert the routing invariant: a legacy-shaped id resolves
  to the legacy store and the path never consults the new store.

  The open-predicate path (#findRunsOpen) is unchanged: an open where
  has no id to route on, so it still unions both stores and dedupes.

  Downloads

  • Source Code (ZIP)
  • Source Code (TAR.GZ)