FAQ
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.

Search Discussions

Discussion Posts

Previous

Follow ups

Related Discussions

Discussion Navigation
viewthread | post
posts ‹ prev | 64 of 77 | next ›
Discussion Overview
grouppgsql-hackers @
categoriespostgresql
postedMay 2, '13 at 12:09p
activeJul 22, '13 at 11:52p
posts77
users9
websitepostgresql.org...
irc#postgresql

People

Translate

site design / logo © 2021 Grokbase