<feed xmlns='http://www.w3.org/2005/Atom'>
<title>pure/research/experiments/024-finding-items/2026-09-30-tpcc-before-2-linux-aarch64.jsonl, branch master</title>
<subtitle>Verified execution runtime unifying state, persistence, and replication.
</subtitle>
<id>http://git.yeowoo.org/pure/atom?h=master</id>
<link rel='self' href='http://git.yeowoo.org/pure/atom?h=master'/>
<link rel='alternate' type='text/html' href='http://git.yeowoo.org/pure/'/>
<updated>2026-09-30T12:52:30Z</updated>
<entry>
<title>Say that prefetching items did not pay, and why (109)</title>
<updated>2026-09-30T12:52:30Z</updated>
<author>
<name>eunhhu</name>
<email>necpition205@gmail.com</email>
</author>
<published>2026-09-30T12:52:30Z</published>
<link rel='alternate' type='text/html' href='http://git.yeowoo.org/pure/commit/?id=68dca986ee7ff7d729a15565e2e07127d5b5d1a4'/>
<id>urn:sha1:68dca986ee7ff7d729a15565e2e07127d5b5d1a4</id>
<content type='text'>
Fetching a found item's cells, a leaf's keys and each level's keys ahead
made finding and reading items 20% faster on 100,000 items in a micro
benchmark, but TPC-C's clean pairs moved 1% at most and finding alone got
48% slower, so it is not in. The owner's finding samples were the descent,
not the fields: a write right after a read copies the leaf whole anyway,
and what costs is walking structures larger than the caches at random.
</content>
</entry>
</feed>
