Natterings about history files

[bill davidsen]

In article <20010210112715.A312 at opentransit.net>,
Fabien Tassin  <fta at sofaraway.org> wrote:

| I've tried to evaluate the gain in having multiple history files but I'm
| not convinced it will be that interesting. The problem is more in
| the expire design than in history. We want it to undo very quickly what has
| been done in a day. A discrete approach should give better results.
| I see two ways to achieve that : a cyclic history (constant size)
| or an expired. The later is easier because it require no change to the
| model to bring the pure CNFS performances to other spool methods. The
| bad point is that it still need to be periodically cleaned.

  I'll throw out an idea which I'm never going to have time to
implement. When an article is removed, by expire or cancel, the only
thing which will need to look at that info will be expire or hishave.
Therefore the info could be moved to one of a series of "expired
history" files, grouped into perhaps 4 hour buckets. When the bucket
reached the /remember/ time it could just be deleted.

  Perhaps this could be delayed until some time after the article (or
cancel for the article) is received, to avoid lookup delays. But after a
day or so, it's unlikely that the info will be needed often enough to
make the performance hit offset the gain in instant expire.

  I haven't done the analysis, it just looks like a cheap way to do
expire of old info and get the info out of the main history, which will
help low memory machines, perhaps.
-- 
bill davidsen <davidsen at tmr.com>
  CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.