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

From Magnus Hagander
Subject Re: win32 performance - fsync question
Date
Msg-id 6BCB9D8A16AC4241919521715F4D8BCE4768E5@algol.sollentuna.se
Whole thread Raw
In response to win32 performance - fsync question  ("E.Rodichev" <er@sai.msu.su>)
Responses Re: win32 performance - fsync question  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
>After multiple runs on different blocksizes( a few anomalous results
>aside), I didn't see a whole lot of difference between
>FILE_FLAG_NO_BUFFERING being on or off for writing performance.
>However, with NO_BUFFERING set, the file is not *read* cached at all.
>While the performance is on not terrible for reads, some careful
>consideration would have to be given for using it outside of WAL.  For
>WAL, though, it seems perfect.  If my results are to be
>believed, we can
>expect up to a 30 yes, that's three + zero times faster sync
>performance
>by ditching FlushFileBuffers (although probably far less in practice).
>

Yes, for WAL it won't blow away read-cache stuff, since we normally
don't expect to read the data that's in WAL.

Is there actually a reason why we don't use O_DIRECT on Unix? From what
I can tell, O_SYNC does the write through but also puts it in the cache,
whereas O_DIRECT doesn't "waste cache" on it?

I was thinking of using O_DIRECT as the "compatibility flag" for the
combination of FILE_FLAG_WRITE_THROUGH and NO_BUFFERING, and using
O_SYNC for just the WRITE_THROUGH. Reasonable?

//Magnus


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: win32 performance - fsync question
Next
From: Tom Lane
Date:
Subject: Re: win32 performance - fsync question