On Wed, Oct 10, 2012 at 9:52 AM, Shaun Thomas <sthomas@xxxxxxxxxxxxxxxx> wrote: > On 10/09/2012 06:30 PM, Craig James wrote: > >> ra:8192 walb:1M ra:256 walb:1M ra:256 walb:256kB >> ---------------- ---------------- ----------------- >> -c -t Run1 Run2 Run3 Run4 Run5 Run6 Run7 Run8 Run9 >> 40 2500 4261 3722 4243 9286 9240 5712 9310 8530 8872 >> 50 2000 4138 4399 3865 9213 9351 9578 8011 7651 8362 > > > I think I speak for more than a few people here when I say: wat. > > About the only thing I can ask, is: did you make these tests fair? And by > fair, I mean: > > echo 3 > /proc/sys/vm/drop_caches > pg_ctl -D /your/pg/dir restart Yes, I was thinking the same. Especially if you check the tendency to perform better in higher-numbered runs. But, as you said, that doesn't explain that jump to twice the TPS. I was thinking, and I'm not pgbench expert, could it be that the database grows from run to run, changing performance characteristics? > My head hurts. I'm just confused. No headache yet. But really interesting numbers in any case. It these results are on the level, then maybe the kernel's read-ahead algorithm isn't as fool-proof as we thought? Gotta read the source. BRB -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
