On 2019-Jun-12, Heikki Linnakangas wrote:
> That was my thought too, when looking at this example. When there is already
> a long queue of transactions, the txtime of individual transactions doesn't
> matter much. The most important thing under that condition is how fast the
> system can dissolve
On 12/06/2019 09:23, Fabien COELHO wrote:
But that was just because I was showing a simplistic example. E.g.
here's a log of a vacuum finishing, and then another starting a few
seconds later (both vacuums lasting a fair while):
progress: 139.0 s, 2438.4 tps, txtime 13.033 ms stddev 3.830, lat 17
On 12/06/2019 02:24, Andres Freund wrote:
But anyway, to go forward, I think we should replace 'lat' with a
'txtime' (or similar) column that is not affected by -R. And then, under
-R only, add a new 'txlat' column, that shows the 'current' meaning of
lat under -R. Not convinced the names are ri
Hello Andres,
On 2019-06-11 11:31:15 +0300, Heikki Linnakangas wrote:
It's not fair to say that its meaning was changed. Before 9.4, there was no
-R option.
Well, my point is that -R changed the existing meaning of a field,
I do not think it does, because the client and transaction latenc
Hi,
On 2019-06-11 11:31:15 +0300, Heikki Linnakangas wrote:
> It's not fair to say that its meaning was changed. Before 9.4, there was no
> -R option.
Well, my point is that -R changed the existing meaning of a field, and
that that's not nice.
> Yeah, I can see that the server-observed transact
On 11/06/2019 10:12, Andres Freund wrote:
On 2019-06-11 08:36:55 +0200, Fabien COELHO wrote:
This behavior under -R is fully voluntary, and the result above just show
that the database cannot really keep up with the load, which is simply the
case, so for me it is okay to show bad figures.
I me
Hi,
On 2019-06-11 08:36:55 +0200, Fabien COELHO wrote:
> > I noticed that pgbench's -R influences not just the computation of lag,
> > but also of latency. That doesn't look right to me, but maybe I'm just
> > missing something?
> >
> > It's quite easy to demonstrate when running pgbench with/wit
Hello Andres,
I noticed that pgbench's -R influences not just the computation of lag,
but also of latency. That doesn't look right to me, but maybe I'm just
missing something?
It's quite easy to demonstrate when running pgbench with/without
progress report at a transaction rate that's around
Hi
On 2019-06-10 21:56:31 -0700, Andres Freund wrote:
> I noticed that pgbench's -R influences not just the computation of lag,
> but also of latency. That doesn't look right to me, but maybe I'm just
> missing something?
I apparently did:
> -P sec
> --progress=sec
>
> Show progress report
