Re: pgbench - exclude pthread_create() from connection start timing

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 #8326. This also helps with throttling,
> as the start time is used to adjust the rate: if it is not the actual
> start time, there is a bit of a rush at the beginning in order to
> catch up. Taking the start time when the thread actually starts is
> the sane thing to do to avoid surprises at possibly strange measures
> on short runs.

On Sun, Sep 22, 2013 at 10:08:54AM +0200, Fabien COELHO wrote:
> I really spent *hours* debugging stupid measures on the previous round of
> 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 taking it just before pthread_create()? We report separate TPS values
for "including connections establishing" and "excluding connections
establishing" because establishing the database connection is expensive,
typically far more expensive than pthread_create(). The patch for threaded
pgbench made the decision to account for pthread_create() as though it were
part of establishing the connection. You're proposing to not account for it
all. Both of those designs are reasonable to me, but I do not comprehend the
benefit you anticipate from switching from one to the other.

> -j 800 vs -j 100 : ITM that if I you create more threads, the time delay
> incurred is cumulative, so the strangeness of the result should worsen.

Not in general; we do one INSTR_TIME_SET_CURRENT() per thread, just before
calling pthread_create(). However, thread 0 is a special case; we set its
start time first and actually start it last. Your observation of cumulative
delay fits those facts. Initializing the thread-0 start time later, just
before calling its threadRun(), should clear this anomaly without changing
other aspects of the measurement.

While pondering this area of the code, it occurs to me -- shouldn't we
initialize the throttle rate trigger later, after establishing connections and
sending startup queries? As it stands, we build up a schedule deficit during
those tasks. Was that deliberate?

Thanks,
nm

--
Noah Misch
EnterpriseDB http://www.enterprisedb.com