Re: RE: [COMMITTERS] pgsql/src/backend/access/transam ( xact.c xlog.c)

Поиск
Список
Период
Сортировка
От Bruce Momjian
Тема Re: RE: [COMMITTERS] pgsql/src/backend/access/transam ( xact.c xlog.c)
Дата
Msg-id 200011161953.OAA26213@candle.pha.pa.us
обсуждение исходный текст
Ответ на Re: RE: [COMMITTERS] pgsql/src/backend/access/transam ( xact.c xlog.c)  (Don Baccus <dhogaza@pacifier.com>)
Ответы Re: RE: [COMMITTERS] pgsql/src/backend/access/transam ( xact.c xlog.c)  (Alfred Perlstein <bright@wintelcom.net>)
Список pgsql-hackers
> At 02:13 PM 11/16/00 -0500, Bruce Momjian wrote:
> 
> >> I think the default should probably be no delay, and the documentation
> >> on enabling this needs to be clear and obvious (i.e. hard to miss).
> >
> >I just talked to Tom Lane about this.  I think a sleep(0) just before
> >the flush would be the best.  It would reliquish the cpu slice if
> >another process is ready to run.  If no other backend is running, it
> >probably just returns.  If there is another one, it gives it a chance to
> >complete.  On return from sleep(0), it can check if it still needs to
> >flush.  This would tend to bunch up flushers so they flush only once,
> >while not delaying cases where only one backend is running.
> 
> This sounds like an interesting approach, yes.

In OS kernel design, you try to avoid process herding bottlenecks. 
Here, we want them herded, and giving up the CPU may be the best way to
do it.

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
853-3000+  If your life is a hard drive,     |  830 Blythe Avenue +  Christ can be your backup.        |  Drexel Hill,
Pennsylvania19026
 


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Larry Rosenman
Дата:
Сообщение: Re: RE: [COMMITTERS] pgsql/src/backend/access/transam ( xact.c xlog.c)
Следующее
От: Larry Rosenman
Дата:
Сообщение: Re: RE: [COMMITTERS] pgsql/src/backend/access/transam ( xact.c xlog.c)