On Wed, Aug 20, 2003 at 12:40:03PM -0400, Vivek Khera wrote:>>>>> "BW" == Bruno Wolff, <Bruno> writes: BW> Also, since at least 7.3, normal vacuums aren't normally going to BW> affect the performance of your database server that much.
I disagree. Triggering a vacuum on a db that is nearly saturating the disk bandwidth has a significant impact.
Vivek is right about this. If your system is already very busy, then a vacuum on a largish table is painful.
I don't actually think having the process done in real time will help, though -- it seems to me what would be more useful is an even lazier vacuum: something that could be told "clean up as cycles are available, but make sure you stay out of the way." Of course, that's easy to say glibly, and mighty hard to do, I expect.
What about a little hint to the buffer management that if it has to evict another buffer to physically read this one (meaning the buffer pool was full already) then it will not put this buffer at the top of the LRU chain but rather at it's end? This way a vacuum on a large table will not cause a complete cache eviction.
Might be a useful hint for sequential scans too.
Jan
-- #======================================================================# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #================================================== [EMAIL PROTECTED] #
---------------------------(end of broadcast)--------------------------- TIP 6: Have you searched our list archives?
http://archives.postgresql.org
