Re: win32 performance - fsync question - Mailing list pgsql-hackers

From Merlin Moncure
Subject Re: win32 performance - fsync question
Date
Msg-id 6EE64EF3AB31D5448D0007DD34EEB3412A762C@Herge.rcsinc.local
Whole thread Raw
In response to win32 performance - fsync question  ("E.Rodichev" <er@sai.msu.su>)
List 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 by date:

Previous
From: Oliver Jowett
Date:
Subject: Re: win32 performance - fsync question
Next
From: "Sergey E. Koposov"
Date:
Subject: Re: Strange RETURN NEXT behaviour in Postgres 8.0