On Tue, Aug 25, 2015 at 6:05 PM, Fabien COELHO <coelho@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