Bruce Momjian <pgman@candle.pha.pa.us> writes:
> Tom Lane wrote:
>> As I recall, that was based on testing on some different platforms.
> But why perfer O_DSYNC over fdatasync if you don't prefer O_SYNC over
> fsync?
It's what tested out as the best bet. I think we were using pgbench
as the test platform, which as you know I have doubts about, but at
least it is testing one actual write/sync pattern Postgres can generate.
The choice between the open flags and fdatasync/fsync depends a whole
lot on your writing patterns (how much data you tend to write between
fsync points), so I don't have a lot of faith in randomly-chosen test
programs as a guide to what to use for Postgres.
>> What does that mean? You can't fsync a closed file.
> You reopen and fsync.
Um. I just looked at that test program, and I think it needs a whole
lot of work yet.
* Some of the test cases count open()/close() overhead, some don't.
This is bad, especially on platforms like Solaris where open() is
notoriously expensive.
* You really cannot put any faith in measuring a single write,
especially on a machine that's not *completely* idle otherwise.
I'd feel somewhat comfortable if you wrote, say, 1000 8K blocks and
measured the time for that. (And you have to think about how far
apart the fsyncs are in that sequence; you probably want to repeat the
measurement with several different fsync spacings.) It would also be
a good idea to compare writing 1000 successive blocks with rewriting
the same block 1000 times --- if the latter does not happen roughly
at the disk RPM rate, then we know the drive is lying and all the
numbers should be discarded as meaningless.
* The program is claimed to test whether you can write from one process
and fsync from another, but it does no such thing AFAICS.
BTW, rather than hard-wiring the test file name, why don't you let it be
specified on the command line? That would make it lots easier for
people to compare the performance of several disk drives, if they have
'em.
regards, tom lane
