| From: | Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr> |
|---|---|
| To: | Craig Ringer <craig(at)2ndquadrant(dot)com> |
| Cc: | Greg Smith <greg(at)2ndQuadrant(dot)com>, PostgreSQL Developers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: [PATCH] add --throttle to pgbench (submission 3) |
| Date: | 2013-05-28 11:52:51 |
| Message-ID: | alpine.DEB.2.02.1305281344500.12479@localhost6.localdomain6 |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | 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.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Szymon Guz | 2013-05-28 12:04:00 | storing plpython global pointer |
| Previous Message | Pavel Stehule | 2013-05-28 11:34:43 | Re: plpgsql redesign (related to plpgsql check function) |