From: | Peter Geoghegan <pg(at)heroku(dot)com> |
---|---|
To: | Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Cc: | Stephen Frost <sfrost(at)snowman(dot)net> |
Subject: | Re: Performance optimization of btree binary search |
Date: | 2013-12-07 00:53:29 |
Message-ID: | CAM3SWZQ2spWkVOc+PCuqYZJFmzjix_5foF0W8361e4vT9EL3yQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Dec 5, 2013 at 2:19 AM, Peter Geoghegan <pg(at)heroku(dot)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/
--
Peter Geoghegan
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2013-12-07 03:00:45 | Re: Recovery to backup point |
Previous Message | David Johnston | 2013-12-07 00:27:14 | Re: [RFC] Shouldn't we remove annoying FATAL messages from server log? |