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

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.