AW: Re: beta5 ... - Mailing list pgsql-hackers

From Zeugswetter Andreas SB
Subject AW: Re: beta5 ...
Date
Msg-id 11C1E6749A55D411A9670001FA687963368200@sdexcsrv1.f000.d0188.sd.spardat.at
Whole thread Raw
Responses Re: AW: Re: beta5 ...  (Bruce Momjian <pgman@candle.pha.pa.us>)
Re: AW: Re: beta5 ...  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
> > The easy fix is to just set the delay to zero.  Looks like that will fix
> > most of the problem.
> 
> Except that Vadim had a reason for setting it to 5, and I'm loath to see
> that changed unless someone actaully understands the ramifications other
> then increasing performance ...

Vadim originally intended 5 milliseconds, he only read the parameter wrong.
Then noticing, that the parameter is actually microseconds, he iirc decided to
leave it as is because the discussion at that time seemed to lead to the conclusion, 
that a simple yield would be optimal in lack of some sort of detection, and
the select with 5 us seemed closest to that.

At least on AIX it looks like the select with 0 timeout is a noop, and does not
yield the processor. There was discussion, that other OS's (BSD) also does an 
immediate return in case of 0 timeout.

Minimum select(2) delay is 1 msec on AIX (tested with Tom's test.c).

So, what was the case against using yield (2) ?

Andreas


pgsql-hackers by date:

Previous
From: Marko Kreen
Date:
Subject: Re: Bug: aliasing in ORDER BY when UNIONing
Next
From: Peter T Mount
Date:
Subject: Re: beta5 ...