"Tom Lane" <[EMAIL PROTECTED]> writes: > Gregory Stark <[EMAIL PROTECTED]> writes: >> When we checkpoint we write out all dirty buffers. But ISTM we don't really >> need to write out buffers which are dirty but which have an LSN older than >> the >> previous checkpoint. Those represent buffers which were dirtied by a >> non-wal-logged modification, ie, hint bit setting. The other non-wal-logged >> operations will sync the buffer themselves when they're done. > > In the current dispensation we don't really care how long a checkpoint > takes, so I don't see the advantage to be gained.
I agree that just a shifting of i/o to the checkpoint from bgwriter isn't interesting. Saving i/o is still i/o saved -- if it doesn't shorten the checkpoint it reduces its i/o bandwidth demands. But again, I couldn't come up with any realistic scenario where the actual i/o saved is anything more than a token amount. I thought I would toss the idea up in case I was missing something. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com ---------------------------(end of broadcast)--------------------------- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
