Hello Greg,
> The lag computation was not the interesting part of this feature to me. As I
> said before, I considered it more of a debugging level thing than a number
> people would analyze as much as you did. I understand why you don't like it
> though. If the reference time was moved forward to match the transaction end
> each time, I think that would give the lag definition you're looking for.
> That's fine to me too, if Fabien doesn't have a good reason to reject the
> idea. We would need to make sure that doesn't break some part of the design
> too.
I really thing that the information currently computed is useful. First,
as you note, for debug, not really debugging the throttling feature which
works fine, but being able to debug performance if something goes wrong
while running a bench. Another reason why it is useful is that from a
client perspective it measures whether the database system is coping with
the load without incurring additional delays by processing clients
requests (say from the web server) far behind their actual (i.e.
scheduled) occurences.
So my recommendation is : please keep this measure as it, and if you want
the other lag measure, why not add it as well next to the previous one?
--
Fabien.
