Optimize MakeCurrentSnapshotsQuery: single grouped max() pass (SQLite)

[hahn-kev-bot]

Summary

MakeCurrentSnapshotsQuery selects the newest snapshot per entity. It used a first_value() window function and then removed the duplicate rows it produced with GROUP BY s.EntityId. The plan sorted the snapshot/commit join twice:

USE TEMP B-TREE FOR RIGHT PART OF ORDER BY   <- window sort
USE TEMP B-TREE FOR GROUP BY                  <- second pass

This PR replaces it with a single grouped max() aggregation.

How it works

Two facts make the new query sort-free:

• Scanning Snapshots via IX_Snapshots_EntityId delivers rows already grouped by EntityId, so GROUP BY needs no sort.
• max() is a streaming aggregate, so there is no window sort either.

SQLite guarantees that when a query has exactly one min()/max() aggregate, every bare (non-aggregated) column takes its value from the row that produced that max (docs). So s.* is the whole snapshot row whose commit is greatest.

max() needs a single scalar, so the commit order (DateTime, Counter, Id) is encoded as one lexically-ordered text key: DateTime is stored by EF as fixed-width sortable text (the same assumption the old ORDER BY relied on), Counter is a non-negative long zero-padded to 20 digits (covers the full long range) so text order matches numeric order, and Id (a fixed-width GUID) is last.

EXPLAIN QUERY PLAN after the change — both temp B-trees are gone:

SCAN s USING INDEX IX_Snapshots_EntityId
SEARCH c USING INDEX (Id=?)

Provider note

This relies on SQLite's bare-column behaviour and is not valid on other providers (e.g. Postgres). The query is SQLite-only by design; a portable equivalent would be ROW_NUMBER() ... WHERE rn = 1.

Benchmarks

Measured with a standalone Python/SQLite harness (schema and indexes mirroring the EF model), 50k entities, best of several runs:

distribution	original	new
~127k snapshots (with history)	786 ms	497 ms (~37% faster)
~55k snapshots (after pruning)	502 ms	324 ms (~35% faster)

Correctness

The returned result set was verified identical to the previous query for:

• the no-filter case, and
• ignoreChangesAfter filters (including DateTime ties broken by Counter/Id) spanning early, middle and late history.

Testing

Validated at the SQL layer only — the .NET SDK was not available in the environment used to write this, so dotnet test (the RepositoryTests cover CurrentSnapshots) has not been run yet. Please run the suite before merging.

Possible follow-up

Denormalizing the commit sort keys onto Snapshots with a composite index removes the commit join entirely (~3x in the same benchmark), but needs a schema migration — out of scope for this PR.

🤖 Generated with Claude Code

https://claude.ai/code/session_01C2nfncTWgKAjER7Ff4PUMS

---

Generated by Claude Code

[coderabbitai]

Important

Draft PR not reviewed

Draft PRs are not automatically reviewed by default.

• Trigger a manual review

To automatically review draft PRs, update your CodeRabbit configuration:

reviews:
  auto_review:
    drafts: true

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}