Re: [HACKERS] Trivial HugeTLB Benchmark

2007-03-07 Thread Jim Nasby
On Mar 4, 2007, at 3:33 PM, Ryan Cumming wrote: I did another 18 runs, 9 each for huge pages and normal shared memory. The database was reinitialized before every third run with "pgbench -i -s 10". The runs themselves were done with "pgbench -s 10 -c 5 -t 1" Rather than doing that, I thin

Re: [HACKERS] Trivial HugeTLB Benchmark

2007-03-06 Thread Ryan Cumming
On Sun, 2007-03-04 at 10:14 -0800, Tom Lane wrote: > If you did this only once, the results are not really trustworthy; > you need to average several similar runs before you can have much > confidence. pgbench's inter-run variation is usually upwards of 10%, > so trying to draw conclusions about h

Re: [HACKERS] Trivial HugeTLB Benchmark

2007-03-04 Thread Tom Lane
Ryan Cumming <[EMAIL PROTECTED]> writes: > I ran each pgbench after a fresh reboot. I used 85 huge pages reserved at > boot for the huge page test, and none for the normal shared memory test. > Normal shared memory: > -bash-3.00$ pgbench -c 5 -t 1 > starting vacuum...end. > transaction type:

[HACKERS] Trivial HugeTLB Benchmark

2007-03-04 Thread Ryan Cumming
Hey, Out of curiosity I benchmarked PostgreSQL 8.2.3 using huge pages for shared memory. Oracle claims fairly significant speedups with huge pages but I couldn't find any information on PostgreSQL. I used the attached patch to enable huge pages on Linux. The test hardware is a dual Nocona Xeon