Re: [PATCH] pgbench --throttle (submission 7 - with lag measurement)

> So my argumented conclusion is that the issue is somewhere within PQfinish(), 
> possibly in interaction with pgbench doings, but is *NOT* related in any way 
> to the throttling patch, as it is preexisting it. Gregs stumbled upon it 
> because he looked at latencies.

An additional thought:

The latency measures *elapsed* time. As a small laptop is running 30 
clients and their server processes at a significant load, there are a lot 
of context switching going on, so maybe it just happens that the pgbench 
process is switched off and then on as PQfinish() is running, so the point 
would really be that the host is loaded and that's it. I'm not sure of the 
likelyhood of such an event. It is possible that would be more frequent 
after timer_exceeded because the system is closing postgres processes, and 
would depend on what the kernel process scheduler does.

So the explanation would be: your system is loaded, and it shows in subtle 
ways here and there when you do detailed measures. That is life.

Basically this is a summary my (long) experience with performance 
experiments on computers. What are you really measuring? What is really 
happening?

When a system is loaded, there are many things which interact one with the 
other and induce particular effects on performance measures. So usually 
what is measured is not what one is expecting.

Greg thought that he was measuring transaction latencies, but it was 
really client contention in a thread. I thought that I was measuring 
PQfinish() time, but maybe it is the probability of a context switch.

-- 
Fabien.