Some additional tests run on my performance testing

[Sean Chittenden]

> > Did you look at any of the blocksize-related patches that have
> > been floating around?
> 
> I tried his tests on a stock pgsql 7.3.4, twice with an 8K block
> filesystem and twice with a 16K block UFS2 filesystem and measured
> an improvement of about 4% for the 8K filesystem.  (Take this cum
> grano salis though, since this was an informal test and I don't have
> enough data to draw a statistically significant conclusion.)  It
> turns out that the tables in Bill's tests have no indices, so pgsql
> winds up doing practically nothing but sequential reads and
> sequential writes of entire tables.  A more typical database load
> would probably be characterized by mostly random access patterns and
> possibly more synchronous writes to the WAL log.

For the sake of eating my own advice and in an attempt to verify the
numbers you suggest above, I loaded a DB with 8k and 16K blocks
(translation: almost all write activities).

With 8K blocks:
15.188u 3.404s 7:12.27 4.2%     209+340k 1251+0io 0pf+0w
14.867u 3.686s 7:32.54 4.0%     201+327k 1252+0io 0pf+0w

avg wall clock sec to complete: 442

With 16K blocks:
15.192u 3.312s 6:44.43 4.5%     198+322k 1253+0io 0pf+0w
15.120u 3.330s 6:51.43 4.4%     205+334k 1254+0io 0pf+0w

avg wall clock sec to complete: 407

Which is different than what your results suggest, but I'll take the
35sec/8% speedup any day of the week and twice on Sunday.  Granted
these tests were done on my laptop and were 100% write, I'd expect
them to stay about the same across the board.  If someone wants to do
some good read tests, I'd be interested in those results.

-sc

-- 
Sean Chittenden