Natterings about history files

[Bill Davidsen]

On 24 Feb 2001, Russ Allbery wrote:

> 
> Fabien Tassin <fta at sofaraway.org> writes:
> > According to Bill Davidsen:
> 
> >> My view is that trying to eliminate the performance hit of expire is
> >> like trying to improve the code in a bubble sort. No matter how
> >> cleverly you code it, it is still not efficient.
> 
> Well, you still have to perform the functionality of expire in one place
> or another, unless I'm missing something major.

  You have to remove old article information from the history database,
and "seen" information after /remember/. No question about that. But I
have to think this can be done on the fly, rather than batched.

> Oh, BTW, note that for a transit-only server you don't need to store *any*
> information about articles in history other than the fact that you've seen
> the message ID.  You don't have to support article retrieval at all, so
> it's okay for articles to be identified solely by storage token.  That
> simplifies the history file issues dramatically.

  This seems to go opposite the idea of a clean history API, doesn't it?
It means the hash has to be done before the store, remove, or query part
of the history operation. I assume that what you menat.

>             Another approach would be for expire to do the checks
> to see if the articles still exist and expireover just query history for
> every article, but additionally rewrite history entries in place when it
> removes articles (for group-based expire).

-- 
bill davidsen <davidsen at tmr.com>
  CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.