has anyone thought about applying the write-ahead log
to the results of a vacuum that allows both readers and writers?
in other words, couldn't vacuum just record the highest commited
transaction id, say "TX", run the vacuum in a private space,
then apply the write-ahead log for all transactions after "TX"
to the private space, and, finally, update the appropriate system
tables to point to the new version of the tables.
seems to me that this approach, while disk intensive, would work well in
environments where a 24x7 db is critical AND slow periods are acceptable.
of course, this approach is lossy, since the wal could
be active through out the sync by the vacuum process.
in other words, the vacuum could perpetually chase the tail
of an active wal. so the vacuum just gives up after a certain number of
tries.
otherwise, do any fundamental problems exist with this approach?
cheers-john scott
=====
John Scott
Senior Partner
August Associates
email: john@august.com web: http://www.august.com/~jmscott
__________________________________________________
Do You Yahoo!?
Get personalized email addresses from Yahoo! Mail
http://personal.mail.yahoo.com/
