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 200011161913.OAA24602@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)  (Don Baccus <dhogaza@pacifier.com>)
List pgsql-hackers
> At 09:32 AM 11/16/00 -0800, Alfred Perlstein wrote:
> >* Bruce Momjian <pgman@candle.pha.pa.us> [001116 08:59] wrote:
> 
> >> Ewe, so we have this 1/200 second delay for every transaction.  Seems
> >> bad to me.
> >
> >I think as long as it becomes a tunable this isn't a bad idea at
> >all.  Fixing it at 1/200 isn't so great because people not wrapping
> >large amounts of inserts/updates with transaction blocks will
> >suffer.
> 
> 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.

--  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: Stephan Szabo
Date:
Subject: Questions on RI spec (poss. bugs)
Next
From: Don Baccus
Date:
Subject: Re: RE: [COMMITTERS] pgsql/src/backend/access/transam ( xact.c xlog.c)