Because you may want to put something very readable and understandable in
a script and like long options, or have to type it interactively every day
in a terminal and like short ones. Most UNIX commands include both kind.
Would it make sense then to add long versions for all the other standard
On 06/19/13 14:34, Fabien COELHO wrote:
>
>>> The use case of the option is to be able to generate a continuous gentle
>>> load for functional tests, eg in a practice session with students or for
>>> testing features on a laptop.
>>
>> Why does this need two option formats (-H and --throttle)?
>
The use case of the option is to be able to generate a continuous gentle
load for functional tests, eg in a practice session with students or for
testing features on a laptop.
Why does this need two option formats (-H and --throttle)?
On the latest version it is --rate and -R.
Because you m
On 05/01/13 04:57, Fabien COELHO wrote:
>
> Add --throttle to pgbench
>
> Each client is throttled to the specified rate, which can be expressed in
> tps or in time (s, ms, us). Throttling is achieved by scheduling
> transactions along a Poisson-distribution.
>
> This is an update of the previ
On 2013-06-09 17:50:13 +0800, Craig Ringer wrote:
> On 05/31/2013 03:41 PM, Fabien COELHO wrote:
> >
> >>> However I'm not sure that pg_stat_replication currently has the
> >>> necessary information on either side to measure the lag (in time
> >>> transactions, but how do I know when a transaction
On 05/31/2013 03:41 PM, Fabien COELHO wrote:
>
>>> However I'm not sure that pg_stat_replication currently has the
>>> necessary information on either side to measure the lag (in time
>>> transactions, but how do I know when a transaction was committed? or
>>> number of transactions?).
>>
>> The BD
However I'm not sure that pg_stat_replication currently has the
necessary information on either side to measure the lag (in time
transactions, but how do I know when a transaction was committed? or
number of transactions?).
The BDR codebase now has a handy function to report when a transaction
On 2013-05-30 15:54:01 +0800, Craig Ringer wrote:
> On 05/30/2013 03:10 PM, Craig Ringer wrote:
> > On 05/28/2013 07:52 PM, Fabien COELHO wrote:
> >> However I'm not sure that pg_stat_replication currently has the
> >> necessary information on either side to measure the lag (in time
> >> transactio
On 05/30/2013 03:10 PM, Craig Ringer wrote:
> On 05/28/2013 07:52 PM, Fabien COELHO wrote:
>> However I'm not sure that pg_stat_replication currently has the
>> necessary information on either side to measure the lag (in time
>> transactions, but how do I know when a transaction was committed? or
>
On 05/28/2013 07:52 PM, Fabien COELHO wrote:
>
> However I'm not sure that pg_stat_replication currently has the
> necessary information on either side to measure the lag (in time
> transactions, but how do I know when a transaction was committed? or
> number of transactions?).
The BDR codebase n
You can try to use and improve the --progress option in another patch
submission which shows how things are going.
That'll certainly be useful, but won't solve this issue. The thing is
that with asynchronous replication you need to know how long it takes
until all nodes are back in sync, with
On 05/28/2013 04:13 PM, Fabien COELHO wrote:
>
> You can try to use and improve the --progress option in another patch
> submission which shows how things are going.
That'll certainly be useful, but won't solve this issue. The thing is
that with asynchronous replication you need to know how long i
The use case of the option is to be able to generate a continuous gentle
load for functional tests, eg in a practice session with students or for
testing features on a laptop.
If you add this to
https://commitfest.postgresql.org/action/commitfest_view?id=18 I'll
review it next month. I have a
On 05/02/2013 12:56 AM, Greg Smith wrote:
> On 5/1/13 4:57 AM, Fabien COELHO wrote:
>> The use case of the option is to be able to generate a continuous gentle
>> load for functional tests, eg in a practice session with students or for
>> testing features on a laptop.
>
> If you add this to
> https
Hello Greg,
If you add this to
https://commitfest.postgresql.org/action/commitfest_view?id=18 I'll review it
next month.
Ok. Thanks. I just did that.
I have a lot of use cases for a pgbench that doesn't just run at 100%
all the time. I had tried to simulate something with simple sleep
ca
On 5/1/13 4:57 AM, Fabien COELHO wrote:
The use case of the option is to be able to generate a continuous gentle
load for functional tests, eg in a practice session with students or for
testing features on a laptop.
If you add this to
https://commitfest.postgresql.org/action/commitfest_view?id
Add --throttle to pgbench
Each client is throttled to the specified rate, which can be expressed in
tps or in time (s, ms, us). Throttling is achieved by scheduling
transactions along a Poisson-distribution.
This is an update of the previous proposal which fix a typo in the sgml
documentati
17 matches
Mail list logo
