From: | Tatsuo Ishii <ishii(at)postgresql(dot)org> |
---|---|
To: | greg(at)2ndQuadrant(dot)com |
Cc: | coelho(at)cri(dot)ensmp(dot)fr, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: [PATCH] pgbench --throttle (submission 7 - with lag measurement) |
Date: | 2013-07-18 04:42:34 |
Message-ID: | 20130718.134234.1114833276285981060.t-ishii@sraoss.co.jp |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> 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.
Yes, that's exactly what I understand from the code.
> 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 would like to hear from Fabien about the issue too.
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese: http://www.sraoss.co.jp
From | Date | Subject | |
---|---|---|---|
Next Message | Rushabh Lathia | 2013-07-18 04:49:33 | Re: Fix pgstattuple/pgstatindex to use regclass-type as the argument |
Previous Message | Hitoshi Harada | 2013-07-18 04:39:37 | Re: [COMMITTERS] pgsql: Add support for REFRESH MATERIALIZED VIEW CONCURRENTLY. |