Overview changes

[Alex Kiernan]

Russ Allbery <rra at stanford.edu> writes:

> Kiernan, Alex <alexk at demon.net> writes:
> 

[Sorry just back from holiday & catching up]

> > I'd like to add another parameter to OVopensearch, date, which when not
> > zero specifies the lower bound on arrival times which OVsearch will
> > return. Right now I've just hacked something in which does a binary
> > search to pick the right start location for ov3, but just doing the
> > simple loop which was in NEWNEWS will work for overview mechanisms which
> > I haven't really thought about.
> 
> This by itself doesn't make a lot of sense to me in that I can't see how
> the overview interface could support it in a way that would be any faster
> than just calling OVopensearch for the full range and then discarding
> anything below the lower arrival time bound.  But maybe it's intended for
> use in combination with the second one?
> 

For ov3 (which is all I've implemented it for) it relies on the fact
that articles get numbered in order of arrival (thinks... have I
introduced a dependency between innd and the overview manager?).

So once the .IDX mapped you can do a binary search through it to
locate a starting point, before starting the linear search. Like I
said I hacked it in, so currently the code I'm running does:

  OVopensearch()
  ov3binsearch()
  OVsearch()

Where ov3binsearch then advances search->cur based on the binary
required arrival time.

For other overview methods based on databases clearly you could add
another index, for buffindexed, I don't know.

> > The second one is I'd like to add a direction parameter so I can walk
> > backwards through with OVsearch (so I get ARThigh first and ARTlow
> > last); again I think all the mechanisms can easily support this (at
> > least I think I can see how to do it for buffindexed) - I need this one
> > to allow me to reduce the high water mark reported by group to allow me
> > to cap the latest article which will be presented.
> 
> I'm not sure I understand how this reduces the high water mark; the high
> water mark already comes from the overview database.
> 

Completely separate requirement :)

To get the NFS reader stuff working I don't allow articles to arrive
(on the readers) until they've been in the overview database for some
seconds (basically to allow all the various caches to age out). To
report the correct high water mark from GROUP I want to walk backwards
from the most recent article until I find one which is old enough that
we should report it.

> Could you fill in a few more details?  I'm not managing to picture what
> you're doing yet.
> 

Sorry, trying to get too much done before I went away :(

-- 
Alex Kiernan, Principal Engineer, Development, THUS plc