Gregory Stark wrote: > > "Tom Lane" <[EMAIL PROTECTED]> writes: > > > The added WAL volume should be pretty minimal, because only tuples that have > > gone untouched for a long time incur extra work. > > That seems like a weak point in the logic. It seems like it would make VACUUM > which is already an i/o hog even more so. Perhaps something clever can be done > with vacuum_cost_delay and commit_siblings. > > Something like inserting the delay between WAL logging and syncing the log and > writing to the heap. So if another transaction commits in the meantime we can > skip the extra fsync and continue.
Huh, but the log would not be flushed for each operation that the vacuum logs. Only when it's going to commit. -- Alvaro Herrera http://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support ---------------------------(end of broadcast)--------------------------- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
