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                      
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?


Reply via email to