Gregory Stark wrote:
>
> "Tom Lane" <tgl@sss.pgh.pa.us> 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