Bruce Momjian <[EMAIL PROTECTED]> 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 ---------------------------(end of broadcast)--------------------------- TIP 6: Have you searched our list archives? http://archives.postgresql.org