AW: Re: beta5 ...

From: Zeugswetter Andreas SB <ZeugswetterA(at)wien(dot)spardat(dot)at>
To: "'The Hermit Hacker'" <scrappy(at)hub(dot)org>, Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
Cc: Lincoln Yeoh <lyeoh(at)pop(dot)jaring(dot)my>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org
Subject: AW: Re: beta5 ...
Date: 2001-02-19 09:04:43
Message-ID: 11C1E6749A55D411A9670001FA687963368200@sdexcsrv1.f000.d0188.sd.spardat.at
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter T Mount 2001-02-19 09:05:58 Re: beta5 ...
Previous Message Marko Kreen 2001-02-19 08:51:32 Re: Bug: aliasing in ORDER BY when UNIONing