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
