Skip site navigation (1) Skip section navigation (2)

Re: solaris build problem with Sun compilers

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: stange(at)rentec(dot)com
Cc: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, pgsql-ports(at)postgresql(dot)org
Subject: Re: solaris build problem with Sun compilers
Date: 2006-05-12 18:10:31
Message-ID: 12675.1147457431@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-ports
Alan Stange <stange(at)rentec(dot)com> writes:
> Hmmm.   I've just been looking at the last snapshot of the HEAD and 
> s_lock.h is still using an ldstub instruction instead of a cas for the 
> inlined tas() function when gcc is being used.   Having a cas 
> instruction here would probably be an improvement too, right?

[ shrug... ]  The person who submitted the solaris_sparc.s change failed
to provide any evidence that it was anything but cosmetic, so I didn't
worry about changing the equivalent gcc code.  If there's actually a
performance win, please cite chapter and verse.  Also, shouldn't we be
worrying about breaking older Sparc chips?  Does CAS go all the way
back?

> Finally, I noticed that pg_sleep is calling select() for a sleep.  On 
> Solaris, this is a fairly expensive way to get off the run queue 
> compared to just calling nanosleep().   How often do backends go to 
> sleep here under "typical" workloads?

If you actually reach that syscall you're screwed performance-wise
anyhow.  I'm disinclined to mess with OS-specific variants of the
delay logic.

			regards, tom lane

In response to

Responses

pgsql-ports by date

Next:From: Bruce MomjianDate: 2006-05-12 18:14:47
Subject: Re: solaris build problem with Sun compilers
Previous:From: Alan StangeDate: 2006-05-12 17:43:44
Subject: Re: solaris build problem with Sun compilers

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group