AW: Re: beta5 ...

Поиск
Список
Период
Сортировка
От Zeugswetter Andreas SB
Тема AW: Re: beta5 ...
Дата
Msg-id 11C1E6749A55D411A9670001FA687963368200@sdexcsrv1.f000.d0188.sd.spardat.at
обсуждение исходный текст
Ответы Re: AW: Re: beta5 ...  (Bruce Momjian <pgman@candle.pha.pa.us>)
Re: AW: Re: beta5 ...  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: Marko Kreen
Дата:
Сообщение: Re: Bug: aliasing in ORDER BY when UNIONing
Следующее
От: Peter T Mount
Дата:
Сообщение: Re: beta5 ...