> > Earlier, Vadim was talking about arranging to share fsyncs of the WAL > > log file across transactions (after writing your commit record to the > > log, sleep a few milliseconds to see if anyone else fsyncs before you > > do; if not, issue the fsync yourself). That would offer less-than- > > one-fsync-per-transaction performance without giving up any > > guarantees. > > If people feel a compulsion to have a tunable parameter, let 'em tune > > the length of the pre-fsync sleep ... > > Already implemented (without ability to tune this parameter - > xact.c:CommitDelay, - yet). Currently CommitDelay is 5, so > backend sleeps 1/200 sec before checking/forcing log fsync. Should definitely make that tuneable (per installation is imho sufficient), no use in waiting if the dba knows there is only very little concurrency. IIRC DB/2 defaults to not using this "commit pooling". Andreas
Сайт использует файлы cookie для корректной работы и повышения удобства. Нажимая кнопку «Принять» или продолжая пользоваться сайтом, вы соглашаетесь на их использование в соответствии с Политикой в отношении обработки cookie ООО «ППГ», в том числе на передачу данных из файлов cookie сторонним статистическим и рекламным службам. Вы можете управлять настройками cookie через параметры вашего браузера