On Thu, Jun 20, 2019 at 12:49:32AM +0200, Ævar Arnfjörð Bjarmason wrote:
> We do it deterministically, when gc.auto thresholds et al are exceeded > we kick one off without waiting for other stuff, if we can get the lock. > > I don't think this desire to just wait a bit until all the fetches are > complete makes sense as a special-case. > > If, as you noted in <20190619190845.gd28...@sigill.intra.peff.net>, the > desire is to reduce GC CPU use then you're better off just tweaking the > limits upwards. Then you get that with everything, like when you run > "commit" in a for-loop, not just this one special case of "fetch". If you tweak the limit upwards, then you're more likely to exist in the non-gc'd state, where reads are penalized. The gc limit is a tradeoff between paying the price for maintenance work versus paying the price for having an unmaintained state. So the optimal time is generally right after you've finished a big chunk of writing, but before you've started doing a bunch of reading (for continuous operations that are reading and writing, there's probably some periodic crossover point every N units of operation). That said, I doubt it matters more than a few percent either way (if that). So I'm fine if we want to optimize for simplicity. -Peff
