diff --git a/doc/src/sgml/ref/pgbench.sgml b/doc/src/sgml/ref/pgbench.sgml
index 8e728dc094..e9e7b6b5a7 100644
--- a/doc/src/sgml/ref/pgbench.sgml
+++ b/doc/src/sgml/ref/pgbench.sgml
@@ -2309,9 +2309,12 @@ statement latencies in milliseconds:
   <para>
    A limitation of <application>pgbench</application> is that it can itself become
    the bottleneck when trying to test a large number of client sessions.
-   This can be alleviated by running <application>pgbench</application> on a different
-   machine from the database server, although low network latency will be
-   essential.  It might even be useful to run several <application>pgbench</application>
+   First, <application>pgbench</application> should be given enough threads to
+   process its clients, depending on the client-side load induced by benchmarking scripts.
+   A typical setting would be that a thread manages a few clients, say between 2 and 10.
+   Second, it might be advisable to run <application>pgbench</application> on a different
+   machine from the database server, although low network latency will be essential.
+   It might even be useful to run several <application>pgbench</application>
    instances concurrently, on several client machines, against the same
    database server.
   </para>
diff --git a/src/bin/pgbench/pgbench.c b/src/bin/pgbench/pgbench.c
index 08a5947a9e..3d6080fc83 100644
--- a/src/bin/pgbench/pgbench.c
+++ b/src/bin/pgbench/pgbench.c
@@ -5841,6 +5841,15 @@ main(int argc, char **argv)
 	if (nthreads > nclients)
 		nthreads = nclients;
 
+	/*
+	 * The best #client/#thread ratio depends on the induced client-side load, which
+	 * depends on --rate, on the executed scripts, on the server capabilities...
+	 *
+	 * Just warn if the ratio looks high.
+	 */
+	if (nclients > 16 * nthreads)
+		pg_log_warning("over 16 clients per thread, consider using more threads");
+
 	/*
 	 * Convert throttle_delay to a per-thread delay time.  Note that this
 	 * might be a fractional number of usec, but that's OK, since it's just