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.