Andrew Sullivan wrote:
> 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. #
#================================================== JanWieck@Yahoo.com #