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


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Reply via email to