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

From Bruce Momjian
Subject Re: RE: [COMMITTERS] pgsql/src/backend/access/transam ( xact.c xlog.c)
Date
Msg-id 200011161953.OAA26213@candle.pha.pa.us
Whole thread Raw
In response to Re: RE: [COMMITTERS] pgsql/src/backend/access/transam ( xact.c xlog.c)  (Don Baccus <dhogaza@pacifier.com>)
Responses Re: RE: [COMMITTERS] pgsql/src/backend/access/transam ( xact.c xlog.c)
List 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 by date:

Previous
From: Larry Rosenman
Date:
Subject: Re: RE: [COMMITTERS] pgsql/src/backend/access/transam ( xact.c xlog.c)
Next
From: Larry Rosenman
Date:
Subject: Re: RE: [COMMITTERS] pgsql/src/backend/access/transam ( xact.c xlog.c)