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
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?


Search Discussions

Discussion Posts


Follow ups

Related Discussions

Discussion Navigation
viewthread | post
posts ‹ prev | 64 of 77 | next ›
Discussion Overview
grouppgsql-hackers @
postedMay 2, '13 at 12:09p
activeJul 22, '13 at 11:52p



site design / logo © 2021 Grokbase