Re: Runtime analysis

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

In response to

Browse pgsql-general by date

  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 ..]"