On Thu, Dec 5, 2013 at 2:19 AM, Peter Geoghegan <p...@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_3y0dfqyuzk2...@mail.gmail.com -- Peter Geoghegan -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers