On Thursday 28 June 2001 15:33, Steve Wolfe wrote:
> > Hrmm, well, we're running it with fsync disabled, and according to the
> > docs, that should make the WAL_SYNC_METHOD irrelevant. We had
> > unacceptable performance with fsync enabled.
> I'm not as familiar with Solaris as I am with Linux, but I do recall
> seeing benchmarks that show a significant speed increase in many
> applications (as much as 40%) by using the "best" compiler optimization
> flags - you may want to look at what it's being compiled with on your
> machine.
While on this subject, I just reinstalled one of our devel servers with a
fresh RHL 7.1 setup, with software RAID 1 enabled (easy to do with the RHL
graphical installer, FWIW). While I could have just modified the existing
setup to use RAID, I wanted to dink with the partitioning as well -- which is
easiest in a reinstall situation.
RAID 1 doesn't change the PostgreSQL performance on the regression tests
significantly. This machine, on multiple runs of 'time ./pg_regress
--schedule=parallel_schedule' on the same UDMA66 drives without RAID 1 posted
an average 'real' number of 44 seconds. With RAID 1 (and the same drives,
controllers, OS, etc) posts an average of 42 seconds -- not statistically
significant. Yes, $PGDATA was on a RAID device... :-).
So, while PostgreSQL will benefit from the redundancy of the RAID, it neither
suffers significantly from the write overhead, nor does it seem to greatly
benefit from the increased read bandwidth, at least in the limited
performance testing afforded by the regression tests (which have been used
for some time as a crude benchmark).
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11