This is a discussion on Re: Some additional tests run on my performance testing - FreeBSD ; > > 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 ...
> > 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.
email@example.com mailing list
To unsubscribe, send any mail to "firstname.lastname@example.org"