On Fri, Aug 2, 2019 at 2:38 AM Fabien COELHO <coe...@cri.ensmp.fr> wrote: > 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. > 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. 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. > What name would you suggest, if it were to be made available from pgbench > as a builtin, that avoids confusion with "tpcb-like"? I'm not in favor of adding it as a built-in. If we were going to do it, I don't know that we could do better than tcpb-like-2, and I'm not excited about that. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company