On Fri, Jun 13, 2014 at 12:46 PM, Dennis Butterstein <soullinu...@web.de> wrote: > I expect my current changes to be resposible for about 0.2-0.3s for this > query but because of the huge time differences I am not able to quantify my > changes. > > Maybe somebody can tell me about a better approach to quantify my changes or > give me some input on how to get more stable postgres time measurements.
There can be other reasons, but for read-only benchmarks, much of this variability seems to come from the operating system's power management and scheduler. I had some luck in reducing variance on Linux with some tricks. Disable CPU frequency scaling: for i in /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor; do echo performance > $i; done Disable the turbo boost feature if your CPU supports it: echo 1 > /sys/devices/system/cpu/intel_pstate/no_turbo Always launch PostgreSQL and pgbench on a fixed CPU core, using "taskset -c3" And exclude all other processes from this core (locking them to cores 0, 1, 2): ps -A -o pid h |xargs -n1 taskset -cp -a 0-2 >/dev/null Transparent hugepage support may also interfere: echo never > /sys/kernel/mm/transparent_hugepage/defrag echo never > /sys/kernel/mm/transparent_hugepage/enabled I'm sure there are more tricks, but this should get you pretty far. Regards, Marti -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers