On 7/17/13 11:34 PM, Tatsuo Ishii wrote:
> My example is for 1 client case. So concurrent clients are not the
> issue here.
Sorry about that, with your clarification I see what you were trying to
explain now. The code initializes the target time like this:
thread->throttle_trigger = INSTR_TIME_GET_MICROSEC(start);
And then each time a transaction fires, it advances the reference time
forward based on the expected rate:
thread->throttle_trigger += wait;
It does *not* reset thread->throttle_trigger based on when the previous
transaction ended / when the next transaction started. If the goal is
10us transaction times, it beats a steady drum saying the transactions
should come at 10us, 20us, 30us (on average--there's some randomness in
the goals). It does not pay any attention to when the previous
transactions finished.
That means that if an early transaction takes an extra 1000us, every
transaction after that will also show as 1000us late--even if all of
them take 10us. You expect that those later transactions will show 0
lag, since they took the right duration. For that to happen,
thread->throttle_trigger would need to be re-initialized with the
current time at the end of each completed transaction.
The lag computation was not the interesting part of this feature to me. As I said before, I considered it more of a
debugginglevel 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.
--
Greg Smith 2ndQuadrant US greg@2ndQuadrant.com Baltimore, MD
PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.com