| From: | Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr> |
|---|---|
| To: | Greg Smith <greg(at)2ndQuadrant(dot)com> |
| Cc: | Tatsuo Ishii <ishii(at)postgresql(dot)org>, PostgreSQL Developers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: [PATCH] pgbench --throttle (submission 7 - with lag measurement) |
| Date: | 2013-07-17 09:04:40 |
| Message-ID: | alpine.DEB.2.02.1307171059050.3991@localhost6.localdomain6 |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
> The whole concept of "lag" with the rate limit is complicated.
I must agree on that point, their interpretation is subtle.
> At one point I thought this should be a debugging detail, rather than
> exposing the user to it. The problem is that if you do that, you might
> not notice that your limit failed to work as expected. Maybe it's good
> enough in a case like this that the user will see they tried to limit at
> 10000, but they only got 7135, so something must not have worked as
> expected.
Yep. As I suggested in answering to Tatsuo, the process can catch up
later, so you could have 10000 in the end even with something amiss.
--
Fabien.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tatsuo Ishii | 2013-07-17 09:14:35 | Re: [PATCH] pgbench --throttle (submission 7 - with lag measurement) |
| Previous Message | Fabien COELHO | 2013-07-17 08:57:05 | Re: [PATCH] pgbench --throttle (submission 7 - with lag measurement) |