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.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
