The attached curves are for pgbench in a scale-factor-500 database,
postmaster options -F -N 100 -B 3800 on a 4-way Linux machine,
current CVS sources.
I noticed that with the default WAL options, the system was spawning
a checkpoint process every fifteen seconds or so during the pgbench
run. Bad news. (Aside from the I/O implied by the checkpoint itself,
there's a big penalty in increased WAL traffic, since the first update
of any page after a checkpoint dumps that whole page to WAL.)
I bumped up the checkpoint_segments parameter to ensure checkpoints
wouldn't happen so frequently, and for good measure kicked wal_files
up too. As you can see, it helped noticeably --- at the price of
several times as much WAL disk space, of course.
Curiously, I'm seeing no improvement whatever from increasing
checkpoint_segments and wal_files in 7.1.3 on the same hardware and same
test conditions. 7.2 has a better algorithm for managing WAL segments
(recycle rather than delete and recreate), but still it seems odd that
7.1.3 can't benefit at all.
BTW, has anyone experimented with the OSDB benchmark at
http://osdb.sourceforge.net/ ? I'm wondering if it might give
more useful numbers than pgbench does.
regards, tom lane
