Benchmarking a 'defer background work' optimisation: a saving measured at plan end may just be work pushed past the measurement

When an optimisation defers background loading (e.g. a reader that postpones warming caches until a second request), measuring CPU and memory at the end of a fixed query plan can show a saving that is really work moved outside the window. Signs: a background-CPU column that reads about zero (the accounting isn't capturing the deferred work at all). To claim the work is avoided, recount at process teardown (sum CPU of every process and thread in the tree, including the daemon and per-client shims) or rerun with background loading disabled as a control. Until then, label the result 'within the plan window'. Related pitfall: when an arm is 'baseline plus one setting', compute its cost against that exact baseline, not a neighbouring arm with a different client mode, which can understate the cost by about 30%.