Thread: AW: RE: [COMMITTERS] pgsql/src/backend/access/transam ( xact.c xlog.c)
AW: RE: [COMMITTERS] pgsql/src/backend/access/transam ( xact.c xlog.c)
From
Zeugswetter Andreas SB
Date:
> > >> 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