On Tue, Aug 25, 2015 at 6:05 PM, Fabien COELHO <coe...@cri.ensmp.fr> wrote: > >> -- merging pgbench logs: returned with feedback or bump? Fabien has >> concerns about performance regarding fprintf when merging the logs. >> Fabien, Tomas, thoughts? >> -- pgbench - per-transaction and aggregated logs: returned with >> feedback or bump to next CF? Fabien, Tomas, thoughts? > > > I think that both features are worthwhile so next CF would be better, but it > really depends on Tomas.
OK, so let's wait for input from Tomas for now. > The key issue was the implementation complexity and maintenance burden which > was essentially driven by fork-based thread emulation compatibility, but it > has gone away as the emulation has been taken out of pgbench and it is now > possible to do a much simpler implementation of these features. > > The performance issue is that if you have many threads which perform > monstruous tps and try to log them then logging becomes a bottle neck, both > the "printf" time and the eventual file locking... Well, that is life, it is > well know that experimentators influence experiments they are looking at > since Schrödinger, and moreover the --sampling-rate option is already here > to alleviate this problem if needed, so I do not think that it is an issue > to address by keeping the code complex. Honestly, I don't like the idea of having a bottleneck at logging level even if we can leverage it with a logging sample rate, that's a recipe for making pgbench become a benchmark to measure its own contention, while it should put the backend into pressure, particularly when short transactions are used. -- Michael -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
