
> > >> 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.

I don't think anything that simply yields the processor works on 
multiprocessor machines. 

The point is, that fsync is so expensive, that a wait time in the 
milliseconds is needed, and not micro seconds, to really improve
tx throughput for many clients.

I support the default to not delay point, since only a very heavily loaded
database will see a lot of fsyncs in the same millisecond timeslice.
A dba coping with a very heavily loaded database will need to tune 
anyway, so for him one additional config is no problem.

Andreas

Fri, 17 Nov 2000 10:09:52 +0100
Zeugswetter Andreas SB <ZeugswetterA@wien.spardat.at>
AW: RE: [COMMITTERS]  pgsql/src/backend/access/transam
	(  xact.c xlog.c)