Re: [GENERAL] Runtime analysis - Mailing list pgsql-general

From Tom Lane
Subject Re: [GENERAL] Runtime analysis
Date
Msg-id 13785.1509896484@sss.pgh.pa.us
Whole thread Raw
In response to [GENERAL] Runtime analysis  (Neto pr <netoprbr9@gmail.com>)
List pgsql-general
Neto pr <netoprbr9@gmail.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


-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

pgsql-general by date:

Previous
From: Marko Tiikkaja
Date:
Subject: Re: [GENERAL] A possible use case for: "INSERT .. ON CONFLICT DO SELECT [FOR ..]"
Next
From: Mark Fletcher
Date:
Subject: Re: [GENERAL] pg_logical/snapshots directory