Prefetching

FoundationDB rejects a transaction once its read version is more than five seconds old because the resolver keeps only that much write history. Resolver v3 replaces that history with a temporal B+ tree under a memory budget and processes each batch in two phases: one descent routes every read and write begin together and checks the reads, then the accepted writes are applied in key order by cooperative tasks that search and prefetch ahead of a single writer. Under the same 6 GiB budget, v3.8 retains at least 582.9 seconds of conflict history after reclamation begins—2.20× FoundationDB’s calibrated 265-second window. The 5,400-second trace replays in 0.76× FoundationDB’s time on Intel and in comparable time on AMD. These timing comparisons cross sessions: v3.8 used HugeTLB pages, while the archived references used ordinary memory.

Resolver v2 delivers about 2.1× v1’s point-read throughput and 1.5× its range-read throughput in the Intel standalone benchmark. In a synthetic 10,000-read example with uniformly distributed begins, recursive partitioning reduces internal-node routing comparisons by 56%; including the initial leaf searches, the total comparison count falls by 44%. Grouped reads also share predecessor lookup and avoid repeating resolved begin comparisons during the leaf scan. Prefetching brings upcoming nodes and keys toward the cache while other tasks advance, creating distance between each hint and its use to hide memory latency. Writes remain sequential.