[EMAIL PROTECTED] wrote: > On 18 Mar, Tom Lane wrote: > > Josh Berkus <[EMAIL PROTECTED]> writes: > >> 1) This is an OSS project. Why not just recruit a bunch of people on > >> PERFORMANCE and GENERAL to test the 4 different synch methods using real > >> databases? No test like reality, I say .... > > > > I agree --- that is likely to yield *far* more useful results than > > any standalone test program, for the purpose of finding out what > > wal_sync_method to use in real databases. However, there's a second > > issue here: we would like to move sync/checkpoint responsibility into > > the bgwriter, and that requires knowing whether it's valid to let one > > process fsync on behalf of writes that were done by other processes. > > That's got nothing to do with WAL sync performance. I think that it > > would be sensible to make a test program that focuses on this one > > specific question. (There has been some handwaving to the effect that > > everybody knows this is safe on Unixen, but I question whether the > > handwavers have seen the internals of HPUX or AIX for instance; and > > besides we need to worry about Windows now.) > > I could certainly do some testing if you want to see how DBT-2 does. > Just tell me what to do. ;)
To test, you would run from CVS version src/tools/fsync, find the fastest fsync method from the last group of outputs, then try the wal_fsync_method setting to see if the one that tools/fsync says is fastest is actually fastest. However, it might be better to run your tests and get some indication of how frequently writes and fsync's are going to WAL and modify tools/fsync to match what your DBT-2 test does. -- Bruce Momjian | http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073 ---------------------------(end of broadcast)--------------------------- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
