From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | captainx0r(at)yahoo(dot)com |
Cc: | pgsql-performance(at)postgresql(dot)org |
Subject: | Re: Sun vs. Mac |
Date: | 2003-01-14 16:04:52 |
Message-ID: | 16237.1042560292@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
CaptainX0r <captainx0r(at)yahoo(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Sullivan | 2003-01-14 16:08:52 | Re: Sun vs. Mac |
Previous Message | CaptainX0r | 2003-01-14 15:41:21 | Re: Sun vs. Mac |