Re: pgbench rate limiting changes transaction latency computation - Mailing list pgsql-hackers

From Heikki Linnakangas
Subject Re: pgbench rate limiting changes transaction latency computation
Date
Msg-id dd6fbb38-9048-16ea-e1b2-f5013c5489f7@iki.fi
Whole thread Raw
In response to Re: pgbench rate limiting changes transaction latency computation  (Andres Freund <andres@anarazel.de>)
List pgsql-hackers
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 right, but you get the gist.

I'm OK with that.

>> For testing the server under full load, like during that catch up period,
>> testing without -R seems better.
> 
> One area in which postgres is pretty weak, although less bad than we
> used to be, is in is predicatable latency. Most production servers
> aren't run under the highest possible throughput, therefore optimizing
> jitter under loaded but not breakneck speeds is important.
> 
> And to be able to localize where such latency is introduced, it's
> important to see the precise moment things got slower / where
> performance recovered.

I agree with all that. I'm still not convinced the changes you're 
proposing will help much, but if you would find it useful, I can't argue 
with that.

- Heikki



pgsql-hackers by date:

Previous
From: Siarhei Siniak
Date:
Subject: Re: GiST limits on contrib/cube with dimension > 100?
Next
From: Amit Langote
Date:
Subject: Re: BEFORE UPDATE trigger on postgres_fdw table not work