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 30-

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 on

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 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 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 def

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 Soft

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 mudfoot
Quoting Bruce Momjian <[EMAIL PROTECTED]>: > > Have you seen /src/tools/fsync? > I have now. Thanks. ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings

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

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

2004-09-12 Thread mudfoot
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 acquired enough history concerning it. I've taken an initial swipe at figuring out how to optimize sync'ing methods. It's based larg