Re: Sun vs. Mac

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

In response to

Responses

Browse pgsql-performance by date

  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