optimizing overview expiry (or: overview without expiry)

Harald Welte laforge at gnumonks.org
Wed Feb 13 12:57:45 UTC 2002


On Mon, Feb 04, 2002 at 12:32:27PM +0900, Katsuhiro Kondou wrote:

> } b) Include a pointer to the overview information 'ovtoken' into 
> }    CNFSARTICLEHEADER.  This way, at the time cnfs overwrites an article,
> }    it could directly call into the overview code and tell it to remove
> }    information about this article.
> 
> You mean CNFSARTHEADER will be variable length, since
> I think the token needs to include all crossposted
> newsgroups?  And innd needs to read the header before
> writing new article.  I'm not sure how the perfomance
> gets down here.

ouch. I didn't think about crosspostings. variable size CNFSARTHEADER is
of course no option :(  I need to re-think this.  One way would be to have
a fixed size array (thus making the number of possible crossposts a compile-
time default).  This is an ugly hack and sucks. 

What if the overview would contain a linked list about all crossposted
overview entries of one article?  This is fixed-size since it just adds
a linked list header with two pointers to every overview entry.

> }   member, and call into the overview code, which removes overview info for
> }   this article
> 
> I think it's necessary to consider how overview data
> will be removed at the same time.  Just marked as
> expired in index?  Or really delete the data?  The
> former should be fast, but you still need to purge
> old data by expireover.  The latter, I believe, it'll
> be much slower to receiving ariticle.

I was thinking about the two options as well.  just marking it as deleted
and then running some 'defragment' as a cronjob is one idea.

Even better would be if the overview block bitmap indicated if a block is
used or not.  Then once we write a new overview entry, we can look in the
bitmap to find a sufficient number of 'deleted' (i.e. free) overview blocks
and re-use them.  This way there would no 'collapsing' be needed anymore.

> } What do you expect with regard to performance?  Would people be interested
> } if I'd implement this?
> 
> It's interesting, but how do you think of storage methods
> other than cnfs?

To be honest:  I wouldn't care too much.  We could make this new overview method
bount to cnfs, not to be used with any other storage methods.  It's not very
clean, I know...

> Katsuhiro Kondou

-- 
Live long and prosper
- Harald Welte / laforge at gnumonks.org               http://www.gnumonks.org/
============================================================================
GCS/E/IT d- s-: a-- C+++ UL++++$ P+++ L++++$ E--- W- N++ o? K- w--- O- M+ 
V-- PS++ PE-- Y++ PGP++ t+ 5-- !X !R tv-- b+++ !DI !D G+ e* h--- r++ y+(*)


More information about the inn-workers mailing list