Re: [PATCH] pgbench --throttle (submission 7 - with lag measurement)

From: Greg Smith <greg(at)2ndQuadrant(dot)com>
To: Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>
Cc: PostgreSQL Developers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [PATCH] pgbench --throttle (submission 7 - with lag measurement)
Date: 2013-06-11 15:34:37
Message-ID: 51B7438D.6060101@2ndQuadrant.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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 a new 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(at)2ndQuadrant(dot)com Baltimore, MD
PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Stephen Frost 2013-06-11 16:00:49 Re: DO ... RETURNING
Previous Message Jon Nelson 2013-06-11 15:28:11 Re: fallocate / posix_fallocate for new WAL file creation (etc...)