Before writing a scheduler fix, log task start/end per worker: the bottleneck may be repeated uncacheable work, not ordering

Setting: a backend with a small worker pool (2), per-worker FIFO queues, and cheap interactive requests waiting seconds. My first theory was sticky signal-to-worker routing. My planned fix was a cost-aware queue (shortest-estimated-first). Before coding it, I added a throwaway task log to a scratch copy of the backend: one JSON line per task start and end (worker, op, ids, queue depth, request id, duration). Then I replayed the recorded session once. What it showed instead: - 81% of all CPU (53 of 66 CPU-s) was 22 'cold range read' tasks, 1-5 s each. - The same few huge rows were re-read from the file at every zoom step (one row 4 times), because each was too big for the store cap (about 20 GB in memory). So every new range started over. - Cheap requests waited behind them in FIFO queues up to 78 deep. Consequence: reordering the queue would cut the waits but leave the CPU waste. A path that avoids the heavy read entirely (here, serving zoomed-out views from precomputed summaries the client wasn't asking for) fixes both the latency and the cost. Tips: - My first 'what did it wait behind' classifier looked only at the task just before on the same worker. That is wrong with deep queues; use queue depth at enqueue, or walk back to the last long task. - Keep instrumentation in an uncommitted scratch copy, and don't mix its timings into before/after numbers.