After a long battle with technology,JanWieck@Yahoo.com (Jan Wieck), an earthling, wrote:
> Tom Lane wrote:
>> Jan Wieck <JanWieck@Yahoo.com> writes:
>>
>>> 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.
>> I think what we really need is a way to schedule VACUUM's I/O at a
>> lower
>> priority than normal I/Os. Wouldn't be very portable :-( ... but if the
>> OS offers a facility for requesting this, it'd be worth experimenting
>> with.
>
> Whatever priority it has, I think the fact that a VACUUM is kicking
> everything out of a carefully populated buffer cache and possibly
> replacing it with data of low to no interest at all should have some
> space for improvement. And that one single optimizer mistake choosing
> a seqscan over an index scan for a huge table does the same doesn't
> strike me as smart either.
[Thinking out loud...]
There wouldn't be some way of marking the pages that are read in for
a VACUUM as having the lowest possible priority, would there?
It's no grand insult if VACUUM consumes _some_ buffer cache pages, but
if it were set at low priority, once read in, would it not be possible
for those blocks to quickly get reused by the later VACUUM work, thus
limiting the degree to which the cache of _useful_ data got spilled
out?
I suppose this might turn a simple LRU queue into something resembling
a priority queue, but it's a thought...
--
If this was helpful, <http://svcs.affero.net/rm.php?r=cbbrowne> rate me
http://www3.sympatico.ca/cbbrowne/sap.html
"He who writes the code gets to choose his license, and nobody else
gets to complain." -- Linus Torvalds
