mirror of
https://github.com/vitorpamplona/amethyst.git
synced 2026-08-12 01:07:46 +00:00
Claude
3a68927829
Answers 'could a new index beat the INDEXED BY pin without the pin?' for the profiles shape (kind=0 AND pubkey IN(...) ORDER BY created_at DESC). Measured: - stock unhinted: scans query_by_kind_created (1.40ms) — the bug. - pinned composite: seek + tiny sort (0.23ms) — the shipped fix. - new (pubkey,kind,created_at) index, unhinted: STILL scans — no help. - new (kind,pubkey,created_at ASC) index, unhinted: picks the seek (0.23ms) BUT that's a no-stats cost-model artifact — ANALYZE reverts it to the scan (1.47ms). Fragile, and a full duplicate of the DESC composite. Root reason: ORDER BY created_at over a multi-value pubkey IN(...) needs a sort no matter the index (no B-tree gives global created_at order across pubkeys), and SQLite prefers the one sort-free plan — the full-kind scan. Only the explicit pin reliably overrides that. A new index would add write+storage cost on every event for the whole relay, help only this one shape, and break under ANALYZE — so the free, deterministic, scoped pin is strictly better. Diagnostic evidence for the design choice. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_012EZeWww5TJnzBZKPoc6mvU