Indeed. v3 attached fixed the case when nthreads > nclients.
Ok, committed. Thanks!
Thanks!
--
Fabien.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 07/03/2015 07:50 AM, Fabien COELHO wrote:
This doesn't behave correctly if you set -j to greater than -c, and also use
the rate limit option:
Indeed. v3 attached fixed the case when nthreads > nclients.
Ok, committed. Thanks!
- Heikki
--
Sent via pgsql-hackers mailing list (pgsql-hacke
This doesn't behave correctly if you set -j to greater than -c, and also use
the rate limit option:
Indeed. v3 attached fixed the case when nthreads > nclients.
--
Fabien.diff --git a/doc/src/sgml/ref/pgbench.sgml b/doc/src/sgml/ref/pgbench.sgml
index a808546..2517a3a 100644
--- a/doc/src/sgm
This doesn't behave correctly if you set -j to greater than -c, and also use
the rate limit option:
[...]
I think that can be fixed by just setting nthreads internally to nclients, if
nthreads > nclients. But please double-check that the logic used to calculate
throttle_delay makes sense in
On 05/08/2015 03:02 PM, Fabien COELHO wrote:
Remove pgbench constraint that the number of clients must be a multiple of
the number of threads, by sharing clients among threads as evenly as
possible.
Rational: allows to test the database load with any number of client
without unrelated constrain
Minor v2 update to change a not badly chosen variable name.
--
Fabien.diff --git a/doc/src/sgml/ref/pgbench.sgml b/doc/src/sgml/ref/pgbench.sgml
index a808546..2517a3a 100644
--- a/doc/src/sgml/ref/pgbench.sgml
+++ b/doc/src/sgml/ref/pgbench.sgml
@@ -326,8 +326,7 @@ pgbench options dbname
Remove pgbench constraint that the number of clients must be a multiple of
the number of threads, by sharing clients among threads as evenly as
possible.
Rational: allows to test the database load with any number of client
without unrelated constraint. The current setting means for instance
