Re: [PATCH] add --throttle to pgbench (submission 3) - Mailing list pgsql-hackers

From Fabien COELHO
Subject Re: [PATCH] add --throttle to pgbench (submission 3)
Date
Msg-id alpine.DEB.2.02.1305281344500.12479@localhost6.localdomain6
Whole thread Raw
In response to Re: [PATCH] add --throttle to pgbench (submission 3)  (Craig Ringer <craig@2ndquadrant.com>)
Responses Re: [PATCH] add --throttle to pgbench (submission 3)  (Craig Ringer <craig@2ndquadrant.com>)
List pgsql-hackers
>> 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 no replication lag.

> I can probably do it with a custom pgbench script, but I'm tempted to
> add support for timing that part separately with a "wait command" to run
> at the end of the benchmark.

ISTM that a separate process not related to pgbench should try to monitor 
the master-slave async lag, as it is an interesting information anyway...

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?).

-- 
Fabien.



pgsql-hackers by date:

Previous
From: Pavel Stehule
Date:
Subject: Re: plpgsql redesign (related to plpgsql check function)
Next
From: Szymon Guz
Date:
Subject: storing plpython global pointer