On Thu, Sep 30, 2004 at 07:11:29PM -0400, Tom Lane wrote:
> More generally I think that invoking VACUUM processing from the bgwriter
> would be a serious violation of the module hierarchy, and would inflict
> more pain in the form of bugs and maintenance headaches than it could
> possibly be worth. We just this version managed to get smgr decoupled
> from the relcache, like it should have been all along. (bufmgr should
> be too, but I haven't tackled that yet...) This was actually a
> necessary step to make the separate bgwriter feasible. Let's not
> reverse that cleanup in pursuit of dubious optimizations.
Yeah, I thought about the same thing. It would certainly be more modular
to have a vacuum daemon that runs ahead of the page writer.
As for the indexes, would it be reasonable to see if the required index
pages were already in memory?
Ultimately, it's going to depend on the table and access patterns as to
whether this provides a speed improvement. A table with a lot of indexes
and a lot of updates per page might not see much benefit. A table where
updates are spread across the table would more likely benefit even if it
does have to bring index pages into memory. The alternative is the
vacuum running later, having to bring in the base data page, and then
all the indexes anyway. But once there is a list of pages with dead
tuples only one read and one write would be saved, which probably isn't
worth the extra code.
--
Jim C. Nasby, Database Consultant decibel@decibel.org
Give your computer some brain candy! www.distributed.net Team #1828
Windows: "Where do you want to go today?"
Linux: "Where do you want to go tomorrow?"
FreeBSD: "Are you guys coming, or what?"