Re: Commitfest remaining "Needs Review" items - Mailing list pgsql-hackers

From Fabien COELHO
Subject Re: Commitfest remaining "Needs Review" items
Date
Msg-id alpine.DEB.2.10.1508251047100.14257@sto
Whole thread Raw
In response to Re: Commitfest remaining "Needs Review" items  (Michael Paquier <michael.paquier@gmail.com>)
Responses Re: Commitfest remaining "Needs Review" items  (Michael Paquier <michael.paquier@gmail.com>)
List pgsql-hackers
> -- 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.

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.

-- 
Fabien.

pgsql-hackers by date:

Previous
From: Simon Riggs
Date:
Subject: Re: Reducing ClogControlLock contention
Next
From: Simon Riggs
Date:
Subject: Re: Planned release for PostgreSQL 9.5