Note that this is pretty standard stuff with threads, ISTM that it
would solve most of the issues, *but* this is not possible with the
thread fork emulation implemented by pgbench, which really means
no threads at all.
You could do those same things in the fork emulation mode using anonymous
On Sun, Oct 06, 2013 at 09:48:04AM +0200, Fabien COELHO wrote:
Also, I'm not sure of any system used with pgbench that do not have
threads, so ISTM that the thread fork-emulation hack is more or less
useless, and it is pretty masochistic to maintain when adding
features.
Fair point. When
On Tue, Oct 01, 2013 at 02:50:29PM +0200, Fabien COELHO wrote:
I do not think that there is a clean and simple way to take the
start/stop period into account when computing global performances of
a run. The TPC-C benchmark tells to ignore the warmup/closure
period, whatever they are, and only
[oops, resent because stalled, wrong From!]
Hello Noah,
Thread create time seems to be expensive as well, maybe up 0.1
seconds under some conditions (?). Under --rate, this create delay
means that throttling is laging behind schedule by about that time,
so all the first transactions are
Hello Noah,
Thread create time seems to be expensive as well, maybe up 0.1
seconds under some conditions (?). Under --rate, this create delay
means that throttling is laging behind schedule by about that time,
so all the first transactions are trying to catch up.
threadRun() already
On Thu, Sep 26, 2013 at 01:41:01PM +0200, Fabien COELHO wrote:
I don't get it; why is taking the time just after pthread_create() more sane
than taking it just before pthread_create()?
Thread create time seems to be expensive as well, maybe up 0.1
seconds under some conditions (?). Under
pgbench changes, when adding the throttling stuff. Having the start time
taken when the thread really starts is just sanity, and I needed that
just to rule out that it was the source of the strange measures.
I don't get it; why is taking the time just after pthread_create() more sane
than
Concerning one of the eventual would-be split patches...
On Tue, Sep 24, 2013 at 10:41:17PM +0200, Fabien COELHO wrote:
- Take thread start time at the beginning of the thread (!)
Otherwise it includes pretty slow thread/fork system start times in
the measurements. May help with bug
