On Thu, Aug 1, 2019 at 2:53 AM Fabien COELHO <coe...@cri.ensmp.fr> wrote: > All in all, pgbench overheads are small compared to postgres processing > times and representative of a reasonably optimized client application.
It's pretty easy to devise tests where pgbench is client-limited -- just try running it with threads = clients/4, sometimes even clients/2. So I don't buy the idea that this is true in general. > To try to salvage my illustration idea: I could change the name to "demo", > i.e. quite far from "TPC-B", do some extensions to make it differ, eg use > a non-uniform random generator, and then explicitly say that it is a > vaguely inspired by "TPC-B" and intended as a demo script susceptible to > be updated to illustrate new features (eg if using a non-uniform generator > I'd really like to add a permutation layer if available some day). > > This way, the "demo" real intention would be very clear. I do not like this idea at all; "demo" is about as generic a name as imaginable. But I have another idea: how about including this script in the documentation with some explanatory text that describes (a) the ways in which it is more faithful to TPC-B than what the normal pgbench thing and (b) the problems that it doesn't solve, as enumerated by Fabien upthread: "table creation and data types, performance data collection, database configuration, pricing of hardware used in the tests, post-benchmark run checks, auditing constraints, whatever…" Perhaps that idea still won't attract any votes, but I throw it out there for consideration. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company