There's a refactoring possible here that seems to make this whole class of problem go away. If I change pgbench so that PQfinish isn't called for any client until *all* of the clients are actually finished with transactions, the whole issue goes away.
Sure. If the explanation is that because of the load the OS is just switching to a "postgres" process while PQfinish is being called, then waiting for the end of other transactions means that "postgres" processes don't have anything to do anymore, so process switching is much less likely, so nothing would show up... However this is really hiding the underlying fact from the measures rather than solving anything, IMHO.
I'm going to package that hack the right way into its own little change, revisit the throttling code, and then this all should wrap up nicely.
My 0.02€: if it means adding complexity to the pgbench code, I think that it is not worth it. The point of pgbench is to look at a steady state, not to end in the most graceful possible way as far as measures are concerned. On the other end, if it does not add too much complexity, why not!
I'd like to get this one out of the commitfest so I can move onto looking at something else.
Thanks. -- Fabien. -- Sent via pgsql-hackers mailing list (firstname.lastname@example.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers