Hello Robert,
Ok, one thread cannot feed an N core server if enough client are executed
per thread and the server has few things to do.
Right ... where N is, uh, TWO.
Yes, two indeed… For low-work cpu-bound load, given libpq & system
overheads, you cannot really hope for a better deal.
I think that the documentation could be clearer about thread/core
recommendations, i.e. how much ressources you should allocate to pgbench
so that the server is more likely to be the bottleneck, in the "Good
Practices" section.
The point I'm clumsily trying to make is that pgbench-specific overheads
are quite small: Any benchmark driver would have pretty much at least the
same costs, because you have the cpu cost of the tool itself, then the
library it uses, eg lib{pq,c}, then syscalls. Even if the first costs are
reduced to zero, you still have to deal with the database through the
system, and this part will be the same.
I'm not convinced. Perhaps you're right; after all, it's not like
pgbench is doing any real work.
Yep, pgbench is not doing much beyond going from one libpq call to the
next. It can be improved, but the overhead is already reasonably low.
On the other hand, I've repeatedly been annoyed by how inefficient
pgbench is, so I'm not totally prepared to concede that any benchmark
driver would have the same costs, or that it's a reasonably
well-optimized client application. When I run the pgbench, I want to
know how fast the server is, not how fast pgbench is.
Hmmm. You cannot fully isolate components: You can only basically learn
how fast the server is when accessed through a libpq connection, which is
quite reasonable because this is what a user can expect anyway.
--
Fabien.
