Re: win32 performance - fsync question
От | Merlin Moncure |
---|---|
Тема | Re: win32 performance - fsync question |
Дата | |
Msg-id | 6EE64EF3AB31D5448D0007DD34EEB3412A762C@Herge.rcsinc.local обсуждение исходный текст |
Ответ на | win32 performance - fsync question ("E.Rodichev" <er@sai.msu.su>) |
Список | pgsql-hackers |
> "Magnus Hagander" <mha@sollentuna.net> writes: > > Is there actually a reason why we don't use O_DIRECT on Unix? > > Portability, or rather the complete lack of it. Stuff that isn't in the > Single Unix Spec is a hard sell. Well, how about this (ok, maybe I'm way out in left field): Change fsync option from on/off to on/off/O_SYNC. On win32 we treat O_SYNC as opened with FILE_FLAG_WRITE_THROUGH. When we are in O_SYNC mode, all files, WAL or otherwise, are assumed to be synced when written and are therefore not synced during pg_fsync(). WAL syncing may of course be overridden using alternate sync methods in postgresql.conf. I suspect that this will drastically alter windows performance, especially on raid systems. What is TBD is the safety aspect. What I like about this that now are not dealing with a win32-only hack, any unix system now has another performance setting top play with. We also don't touch the O_DIRECT flag (on win32: FILE_FLAG_WRITE_THROUGH | FILE_FLAG_NO_BUFFERING) leaving that can of worms for another day. Under normal situations, we would expect O_SYNCing everything all the time to slow stuff down, especially during checkpoints, but it might actually help on a caching raid controller. On win32, it will help because the performance of fsync() sucks so horribly, even or raid. Merlin
В списке pgsql-hackers по дате отправления: