Re: [PATCH] pgbench --throttle (submission 7 - with lag measurement)

From: Tatsuo Ishii <ishii(at)postgresql(dot)org>
To: greg(at)2ndQuadrant(dot)com, coelho(at)cri(dot)ensmp(dot)fr
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: [PATCH] pgbench --throttle (submission 7 - with lag measurement)
Date: 2013-07-18 05:04:14
Message-ID: 20130718.140414.281967846374669830.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.

For your information, included is the patch against git master head to
implement the lag in a way what I proposed. With the patch, I get more
consistent number on Linux (and Mac OS X).
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese: http://www.sraoss.co.jp

Attachment Content-Type Size
pgbench-throttle-ishii.patch text/x-patch 11.5 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Fabien COELHO 2013-07-18 07:48:43 Re: [PATCH] pgbench --throttle (submission 7 - with lag measurement)
Previous Message Atri Sharma 2013-07-18 05:02:13 Re: Proposal/design feedback needed: WITHIN GROUP (sql standard ordered set aggregate functions)