From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Neto pr <netoprbr9(at)gmail(dot)com> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: Runtime analysis |
Date: | 2017-11-05 15:41:24 |
Message-ID: | 13785.1509896484@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Neto pr <netoprbr9(at)gmail(dot)com> writes:
> I expected that the first run would always take longer than the others
> because of not having cached data, but look what happened:
> - in 6 cases the first execution was more faster than all executions.
> - in 2 cases only, the first exececution was more slower than all
> executions
> If anyone has any suspicion or explanation, why in some cases the first
> execution can be faster than the others, please reply to this email.
Your Xeon is probably a variable-speed chip; did you take measures to
freeze the CPU frequency? On my RHEL server, I generally can't get
very reproducible numbers from benchmarks unless I first do
"sudo cpupower frequency-set --governor performance"
because the default "ondemand" governor is too eager to ratchet down
the frequency. Things might be different on Debian though.
In multi-socket servers, NUMA effects across sockets can be a big
headache too.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Mark Fletcher | 2017-11-05 16:11:36 | Re: pg_logical/snapshots directory |
Previous Message | Marko Tiikkaja | 2017-11-05 15:06:08 | Re: A possible use case for: "INSERT .. ON CONFLICT DO SELECT [FOR ..]" |