CaptainX0r <captainx0r@yahoo.com> writes:
> I've read that somewhere (maybe in the archives?) and I got no
> change with any of them. But now I'm thinking back - do I need
> fsync=true for that to have an affect? I'm not worried about
> the cons of having fsync=false at all - and I'm assuming that
> should be better than true and open_datasync.
You are right that fsync_method is a no-op if you've got fsync turned
off.
Let me get this straight: the Sun is slower even with fsync off? That
shoots down the first theory that I had, which was that the Sun's disk
drives were actually honoring fsync while the laptop's drive does not.
(See archives for more discussion of that, but briefly: IDE drives are
commonly set up to claim write complete as soon as they've absorbed
data into their onboard buffers. SCSI drives usually tell the truth
about when they've completed a write.)
Andrew Sullivan's nearby recommendation to replace qsort() is a good
one, but PG 7.3 is already configured to do that by default. (Look in
src/Makefile.global to confirm that qsort.o is mentioned in LIBOBJS.)
I'd suggest starting with some elementary measurements, for example
looking at I/O rates and CPU idle percentage while running the same
task on both Solaris and G3. That would at least give us a clue whether
I/O or CPU is the bottleneck.
regards, tom lane
