Jan Wieck wrote: > Tom Lane wrote: > > > "Zeugswetter Andreas SB SD" <[EMAIL PROTECTED]> writes: > >> So Imho the target should be to have not much IO open for the checkpoint, > >> so the fsync is fast enough, even if serial. > > > > The best we can do is push out dirty pages with write() via the bgwriter > > and hope that the kernel will see fit to write them before checkpoint > > time arrives. I am not sure if that hope has basis in fact or if it's > > just wishful thinking. Most likely, if it does have basis in fact it's > > because there is a standard syncer daemon forcing a sync() every thirty > > seconds. > > Looking at the response time charts I did for showing how vacuum delay > is doing, it seems at least on Linux there is hope that that is the > case. Those charts have just a regular 5 minute checkpoint with enough > checkpoint segments for that, and no other sync effort done at all. > > The system has a hard time to handle a larger scaled test DB, so it is > definitely well saturated with IO. The charts are here: > > http://developer.postgresql.org/~wieck/vacuum_cost/ > > > > > That means that instead of an I/O storm every checkpoint interval, > > we get a smaller I/O storm every 30 seconds. Not sure this is a big > > improvement. Jan already found out that issuing very frequent sync()s > > isn't a win. > > In none of those charts I can see any checkpoint caused IO storm any > more. Charts I'm currently doing for 7.4.1 show extremely clear spikes > at checkpoints. If someone is interested in those as well I will put > them up.
So, Jan, are you basically saying that the background writer has solved the checkpoint I/O flood problem, and we just need to deal with changing sync to multiple fsync's at checkpoint? -- 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
