On Tue, Jun 11, 2024 at 5:49 AM Bertrand Drouvot <bertranddrouvot...@gmail.com> wrote: > As we can see the actual wait time is 30ms less than the intended wait time > with > this simple test. So I still think we should go with 1) actual wait time and > 2) > report the number of waits (as mentioned in [1]). Does that make sense to you?
I like the idea of reporting the actual wait time better, provided that we verify that doing so isn't too expensive. I think it probably isn't, because in a long-running VACUUM there is likely to be disk I/O, so the CPU overhead of a few extra gettimeofday() calls should be fairly low by comparison. I wonder if there's a noticeable hit when everything is in-memory. I guess probably not, because with any sort of normal configuration, we shouldn't be delaying after every block we process, so the cost of those gettimeofday() calls should still be getting spread across quite a bit of real work. That said, I'm not sure this experiment shows a real problem with the idea of showing intended wait time. It does establish the concept that repeated signals can throw our numbers off, but 30ms isn't much of a discrepancy. I'm worried about being off by a factor of two, or an order of magnitude. I think we still don't know if that can happen, but if we're going to show actual wait time anyway, then we don't need to explore the problems with other hypothetical systems too much. I'm not convinced that reporting the number of waits is useful. If we were going to report a possibly-inaccurate amount of actual waiting, then also reporting the number of waits might make it easier to figure out when the possibly-inaccurate number was in fact inaccurate. But I think it's way better to report an accurate amount of actual waiting, and then I'm not sure what we gain by also reporting the number of waits. -- Robert Haas EDB: http://www.enterprisedb.com
