Re: [PATCH] pgbench --throttle (submission 7 - with lag measurement) - Mailing list pgsql-hackers

From Fabien COELHO
Subject Re: [PATCH] pgbench --throttle (submission 7 - with lag measurement)
Date
Msg-id alpine.DEB.2.02.1306112254010.10500@localhost6.localdomain6
Whole thread Raw
In response to Re: [PATCH] pgbench --throttle (submission 7 - with lag measurement)  (Greg Smith <greg@2ndQuadrant.com>)
List pgsql-hackers
>>   - ISTM that there "thread start time" should be initialized at the
>>     beginning of threadRun instead of in the loop *before* thread creation,
>>     otherwise the thread creation delays are incorporated in the
>>     performance measure, but ISTM that the point of pgbench is not to
>>     measure thread creation performance...
>
> I noticed that, but it seemed a pretty minor issue.

Not for me, because the "max lag" measured in my first version was really 
the threads creation time, not very interesting.

> Did you look at the giant latency spikes at the end of the test run I 
> submitted the graph for?

I've looked at the graph you sent. I must admit that I did not understand 
exactly what is measured and where it is measured. Because of its position 
at the end of the run, I thought of some disconnection related effects 
when pgbench run is interrupted by a time out signal, so some things are 
done more slowly. Fine with me, we are stopping anyway, and out of the 
steady state.

> I wanted to nail down what was causing those before worrying about the 
> startup timing.

Well, the short answer is that I'm not worried by that, for the reason 
explained above. I would be worried if it was anywhere else but where the 
transactions are interrupted, the connections are closed and the threads 
are stopped. I may be wrong:-)

-- 
Fabien.



pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: request a new feature in fuzzystrmatch
Next
From: Liming Hu
Date:
Subject: Re: request a new feature in fuzzystrmatch