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.1307142231060.3991@localhost6.localdomain6
Whole thread Raw
In response to Re: [PATCH] pgbench --throttle (submission 7 - with lag measurement)  (Greg Smith <greg@2ndQuadrant.com>)
Responses Re: [PATCH] pgbench --throttle (submission 7 - with lag measurement)
List pgsql-hackers
Hello Greg,

> Correct patch (and the little one from me again) attached this time.

Please find an updated v15 with only comment changes:

* The new comment about "is_throttled" was inverted wrt the meaning of the 
variable, at least to my understanding.

* ISTM that the impact of the chosen 1000 should appear somewhere.

* The trans_need_throttle comment was slightly wrong: the first 
transaction is also throttled, when initially entering doCustom.


About 123456 12345 vs 123456.012345: My data parser is usually "gnuplot" 
or "my eyes", and in both cases the later option is better:-)


About the little patch: Parameter "ok" should be renamed to something 
meaningful (say "do_finish"?). Also, it seems that when timer is exceeded 
in doCustom it is called with true, but maybe you intended that it should 
be called with false?? Moreover, under normal circumstances (throttling is 
significantly below the maximum rate) PQfinish will be called directly by 
threadRun while interrupting sleeping threads. Also, it is important to 
remove the connection because it serves as a marker to know whether a 
client must run or not. So basically I do not understand how it works. 
Note that it does not mean that it does not work, it just means that I do 
not really understand:-)

-- 
Fabien.

pgsql-hackers by date:

Previous
From: james
Date:
Subject: Re: Improvement of checkpoint IO scheduler for stable transaction responses
Next
From: Greg Smith
Date:
Subject: Re: Improvement of checkpoint IO scheduler for stable transaction responses