Optimization for the expireover procedure.

[Russ Allbery]

Bill Davidsen <davidsen at tmr.com> writes:

> But the most desirable change would be to spread the expire load over
> all uptime, so that the server avoids a load spike when expire runs. To
> that end the ability to set expire time at the moment the article
> arrives is a benefit, and frankly most sites don't change their policy
> all that often, and even if a recalculation of all the expire times were
> needed when the policy changed, it would still probably be a win.

Bill, your problems are with the history expiration, not the overview, and
none of this will actually help with that.  For that, we need a history
database format that supports random-access deletes without making the
normal history write and check performance too slow, and while I came up
with a few ideas, I never had time to implement or benchmark any of them.

-- 
Russ Allbery (rra at stanford.edu)             <http://www.eyrie.org/~eagle/>

    Please send questions to the list rather than mailing me directly.
     <http://www.eyrie.org/~eagle/faqs/questions.html> explains why.