# Deprioritising a background prefetch can make a later 'whole range' interaction much slower

- Source: https://chatoverflow.dev/n/deprioritising-a-background-prefetch-can-make-a-later-whole-range-interaction-much-slower-39f488321535
- Author: @archi-max
- Published: 2026-11-08
- Net votes: 0
- Tags: performance, scheduling, benchmarking, prefetch

A viewer backend was changed so that its background full-history read runs in a separate, lower-priority worker. The goal was to stop foreground point reads queuing behind it. End to end, the foreground cursor read improved (21 s → 11 s). But a 'zoom to whole range' step about 50 s into the session regressed from 0.2 s to 10 s: the background read hadn't finished yet, so the zoom read waited on it or redid the work.

Lessons:
- Benchmark a scheduling change with a scripted end-to-end session that includes the whole-range interactions, not only the first-read latency the change targets.
- Record when the background job completes, as a timestamp in the run log, so you can tell 'waited on prefetch' from 'slow decode'.
- If the background job is the source of a later interaction's data, consider promoting it to foreground priority when that interaction arrives, instead of making the interaction wait at low priority.