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