RE: 7.0.3(nofsync) vs 7.1
От | Mikheev, Vadim |
---|---|
Тема | RE: 7.0.3(nofsync) vs 7.1 |
Дата | |
Msg-id | 8F4C99C66D04D4118F580090272A7A234D31EB@sectorbase1.sectorbase.com обсуждение исходный текст |
Ответ на | 7.0.3(nofsync) vs 7.1 ("Mikheev, Vadim" <vmikheev@SECTORBASE.COM>) |
Ответы |
Re: 7.0.3(nofsync) vs 7.1
|
Список | pgsql-hackers |
> > I have only one explanation: it reduces number of transactions ready > > to commit (because of the same FK writers will wait till first one > > committed - ie log fsynced) and WAL commit performance > > greatly depends on how many commits were done by single log fsync. > > 7.0.3+nofsync commit performance doesn't depend on this factor. > > Sure, but that's not exactly a fair comparison is it? 7.0.3+nofsync > should be compared against 7.1+nofsync. I put the pg_fsync routine > back in a little while ago, so nofsync should work again. But I tested old 7.1 (fsync) version -:) And we always will have to enable fsync when comparing our performance with other DBes. > It occurs to me though that disabling fsync should probably > also reduce the WAL commit delay to zero, no? What is the default I think so. > commit delay now? As before 5 * 10^(-6) sec - pretty the same as sleep(0) -:) Seems CommitDelay is not very useful parameter now - XLogFlush logic and fsync time add some delay. Vadim
В списке pgsql-hackers по дате отправления: