Re: [PATCH] pgbench --throttle (submission 7 - with lag measurement) - Mailing list pgsql-hackers

From Greg Smith
Subject Re: [PATCH] pgbench --throttle (submission 7 - with lag measurement)
Date
Msg-id 51B7438D.6060101@2ndQuadrant.com
Whole thread Raw
In response to Re: [PATCH] pgbench --throttle (submission 7 - with lag measurement)  (Fabien COELHO <coelho@cri.ensmp.fr>)
Responses Re: [PATCH] pgbench --throttle (submission 7 - with lag measurement)  (Fabien COELHO <coelho@cri.ensmp.fr>)
Re: [PATCH] pgbench --throttle (submission 7 - with lag measurement)  (Fabien COELHO <coelho@cri.ensmp.fr>)
List pgsql-hackers
On 6/10/13 6:02 PM, Fabien COELHO wrote:
>   - the tps is global, with a mutex to share the global stochastic process
>   - there is an adaptation for the "fork" emulation
>   - I do not know wheter this works with Win32 pthread stuff.

Instead of this complexity, can we just split the TPS input per client?  That's all I was thinking of here, not adding
anew set of threading 
 
issues.  If 10000 TPS is requested and there's 10 clients, just set the 
delay so that each of them targets 1000 TPS.

I'm guessing it's more accurate to have them all communicate as you've 
done here, but it seems like a whole class of new bugs and potential 
bottlenecks could come out of that.  Whenever someone touches the 
threading model for pgbench it usually gives a stack of build farm 
headaches.  Better to avoid those unless there's really a compelling 
reason to go through that.

-- 
Greg Smith   2ndQuadrant US    greg@2ndQuadrant.com   Baltimore, MD
PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.com



pgsql-hackers by date:

Previous
From: Jon Nelson
Date:
Subject: Re: fallocate / posix_fallocate for new WAL file creation (etc...)
Next
From: Stephen Frost
Date:
Subject: Re: DO ... RETURNING