Re: [PERFORM] Determine optimal fdatasync/fsync, O_SYNC/O_DSYNC options

2004-09-14 Thread Vivek Khera
TL == Tom Lane [EMAIL PROTECTED] writes: TL Bruce Momjian [EMAIL PROTECTED] writes: If we had a majority of queries filling more than one block we would be checkpointing like crazy and we don't normally get reports about that. TL [ raised eyebrow... ] And of course the

Re: [PERFORM] Determine optimal fdatasync/fsync, O_SYNC/O_DSYNC options

2004-09-13 Thread Bruce Momjian
Have you seen /src/tools/fsync? --- [EMAIL PROTECTED] wrote: Hi, I'd like to help with the topic in the Subject: line. It seems to be a TODO item. I've reviewed some threads discussing the matter, so I hope I've

Re: [PERFORM] Determine optimal fdatasync/fsync, O_SYNC/O_DSYNC options

2004-09-13 Thread Gaetano Mendola
Bruce Momjian wrote: Have you seen /src/tools/fsync? Now that the argument is already open, why postgres choose on linux fdatasync? I'm understanding from other posts that on this platform open_sync is better than fdatasync. However I choose open_sync. During initdb why don't detect this parameter

Re: [PERFORM] Determine optimal fdatasync/fsync, O_SYNC/O_DSYNC options

2004-09-13 Thread Josh Berkus
Gaetano, Now that the argument is already open, why postgres choose on linux fdatasync? I'm understanding from other posts that on this platform open_sync is better than fdatasync. Not necessarily. For example, here's my test results, on Linux 2.6.7, writing to a ReiserFS mount on a

Re: [PERFORM] Determine optimal fdatasync/fsync, O_SYNC/O_DSYNC options

2004-09-13 Thread Tom Lane
Gaetano Mendola [EMAIL PROTECTED] writes: Now that the argument is already open, why postgres choose on linux fdatasync? I'm understanding from other posts that on this platform open_sync is better than fdatasync. AFAIR, we've seen *one* test from *one* person alleging that. And it was

Re: [PERFORM] Determine optimal fdatasync/fsync, O_SYNC/O_DSYNC options

2004-09-13 Thread Bruce Momjian
Tom Lane wrote: The tests that started this thread are pretty unconvincing in my eyes, because they are comparing open_sync against code that fsyncs after each one-block write. Under those circumstances, *of course* fsync will lose (or at least do no better), because it's forcing the same

Re: [PERFORM] Determine optimal fdatasync/fsync, O_SYNC/O_DSYNC options

2004-09-13 Thread Gaetano Mendola
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Tom Lane wrote: | Gaetano Mendola [EMAIL PROTECTED] writes: | |Now that the argument is already open, why postgres choose |on linux fdatasync? I'm understanding from other posts that |on this platform open_sync is better than fdatasync. | | | AFAIR,

Re: [PERFORM] Determine optimal fdatasync/fsync, O_SYNC/O_DSYNC options

2004-09-13 Thread Tom Lane
Bruce Momjian [EMAIL PROTECTED] writes: If we had a majority of queries filling more than one block we would be checkpointing like crazy and we don't normally get reports about that. [ raised eyebrow... ] And of course the 30-second-checkpoint-warning stuff is a useless feature that no one