AW: Re: beta5 ...
От | Zeugswetter Andreas SB |
---|---|
Тема | AW: Re: beta5 ... |
Дата | |
Msg-id | 11C1E6749A55D411A9670001FA687963368200@sdexcsrv1.f000.d0188.sd.spardat.at обсуждение исходный текст |
Ответы |
Re: AW: Re: beta5 ...
Re: AW: Re: beta5 ... |
Список | 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 по дате отправления: