On Thu, Dec 5, 2013 at 2:19 AM, Peter Geoghegan <pg@heroku.com> wrote:
> I did a relatively short variant 'insert' pgbench-tools benchmark,
> with a serial primary index created on the pgbench_history table.
> Results:
>
> http://postgres-benchmarks.s3-website-us-east-1.amazonaws.com/insert/
I saw something today that made me lose confidence in the results I've
presented. I was unsuccessful in re-creating similar 'select' numbers
at scale 15 on the same server [1] (originally I wanted to see how
eliding the fmgr trapoline worked out with binary searching only).
Then, when re-testing master as of commit
8e18d04d4daf34b8a557e2dc553a7754b255cd9a (my feature branches branched
off from that master commit), I noticed that even after the last
pgbench had run, a single postgres process was stuck at 100% CPU usage
for upwards of a minute (the run referred to was for 32 clients, and I
only saw that one process in 'top' output).
To me this points to either 1) some kind of contamination or 2) a bug
in Postgres. My first guess is that it's the issue described here [2]
and elsewhere (maybe whether or not that behavior constitutes a bug in
controversial, but I think it does).
Consider the contrast between these two runs (against master, 2
clients) of the same, new benchmark:
http://postgres-benchmarks.s3-website-us-east-1.amazonaws.com/new-select/50/index.html
http://postgres-benchmarks.s3-website-us-east-1.amazonaws.com/new-select/44/index.html
I had considered that something like Intel Speedstep technology had a
role here, but I'm pretty sure it steps up very aggressively when
things are CPU bound - I tested that against a Core 2 Duo desktop a
couple of years back, where it was easy to immediately provoke it by
moving around desktop windows or something. I know that Greg Smith
controls for that by disabling it, but I have not done so here - I
assumed that he only did so because he was being particularly
cautious. There are similar runs on my original 'results' benchmark
(these particular should-be-comparable-but-are-not runs are with 1
client against my patch this time):
http://postgres-benchmarks.s3-website-us-east-1.amazonaws.com/results/297/index.html
http://postgres-benchmarks.s3-website-us-east-1.amazonaws.com/results/303/index.html
References:
[1] http://postgres-benchmarks.s3-website-us-east-1.amazonaws.com/new-select/
[2] http://www.postgresql.org/message-id/CAFj8pRDDa40eiP4UTrCm=+Bdt0xbWF7qC8T_3y0dFqYuZk2YAg@mail.gmail.com
--
Peter Geoghegan