| Comment: | prefix lookups seek instead of scanning; sqlite tuned for this workload
col LIKE ? || '%' cannot use an index: the pattern is not a literal when the statement is prepared, so finding ONE check-in by its full hash read all 36,853 rows of sqlite's tree. That was 10s on a first timeline render and 40ms after, which reads as cold I/O and is not. Half-open hex ranges seek. Also sets cache_size, mmap_size and temp_store, none of which were configured. |
|---|---|
| Timelines: | family | ancestors | descendants | both | trunk |
| Files: | files | file ages | folders |
| SHA3-256: |
22346a81a74f709412c52c1ca62e0c3b |
| User & Date: | quarry on 2026-08-31 13:14:29.184 |
| Other Links: | manifest | tags |
|
2026-08-31
| ||
| 13:16 |
warm the leaf set instead of making a reader pay for it
zit leaves is 6.4s on sqlite, not the ~10ms this comment claimed, and the first reader paid it: 10.8s cold against 0.5s warm. Invisible in the footer too, since a detached context carries no timer. Warmed at registration and after each ingest; a reader arriving early gets no leaf marks rather than a six-second wait. check-in: e16d738900 user: quarry tags: trunk | |
| 13:14 |
prefix lookups seek instead of scanning; sqlite tuned for this workload
col LIKE ? || '%' cannot use an index: the pattern is not a literal when the statement is prepared, so finding ONE check-in by its full hash read all 36,853 rows of sqlite's tree. That was 10s on a first timeline render and 40ms after, which reads as cold I/O and is not. Half-open hex ranges seek. Also sets cache_size, mmap_size and temp_store, none of which were configured. check-in: 22346a81a7 user: quarry tags: trunk | |
| 12:57 |
name the slow op in the log
A ten-second page said 'ops 11.09s x8' and stopped there: the container is timed, its contents are not, so the slow one cannot be identified. Anything past 250ms now says which op it was. check-in: 3f926fafe8 user: quarry tags: trunk | |