Jan Wieck wrote: > If the system is write-bound, the checkpointer will find that many dirty > blocks that he has no time to nap and will burst them out as fast as > possible anyway. Well, at least that's the theory. > > PostgreSQL with the non-overwriting storage concept can never have > hot-written pages for a long time anyway, can it? They fill up and cool > down until vacuum.
Another idea on removing sync() --- if we are going to use fsync() on each file during checkpoint (open, fsync, close), seems we could keep a hash of written block dbid/relfilenode pairs and cycle through that on checkpoint. We could keep the hash in shared memory, and dump it to a backing store when it gets full, or just have it exist in buffer writer process memory (so it can grow) and have backends that do their own buffer writes all open a single file in append mode and write the pairs to the file, or something like that, and the checkpoint process can read from there. -- 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 6: Have you searched our list archives? http://archives.postgresql.org
