I've summed up the result of this thread here:
http://picolisp.com/5000/-2-I.html with some explanations.
On Fri, May 14, 2010 at 8:59 AM, Henrik Sarvell <hsarv...@gmail.com> wrote:
> OK since I can't rely on sorting by date anyway let's forget that idea.
> Yes since it seemed I had to involve dates anyway I simply chose a
> date far back enough in time that if someone is looking for something
> they might as well use Google.
> Anyway the above is scanning 19 remotes containing indexes for 10 000
> articles each and returns in 3-4 seconds which is OK for me, problem
> solved as far as I'm concerned. I have to add though that all remotes
> are currently on the same machine, had they been truly distributed it
> would be faster, especially if the other machines were in the same
> data center.
> On Fri, May 14, 2010 at 7:55 AM, Alexander Burger <a...@software-lab.de>
>> On Thu, May 13, 2010 at 09:12:06PM +0200, Henrik Sarvell wrote:
>>> One thing first though, since articles are indexed when they're parsed
>>> and PL isn't doing any kind of sorting automatically on insert then
>>> they should be sorted by date automatically with the latest articles
>>> at the end of the database file since I suppose they're just appended?
>> While this is correct in principle, I would not rely on it. If there
>> should ever be an object deleted from that database file, the space
>> would be reused by the next new object, and the assumption would break.
>>> How can I simply start walking from the end of the file until I've
>>> found say 25 matches? This procedure should be the absolutely fastest
>>> way of getting what I want.
>> Currently I see no easy way. The only function that walks a database
>> file directly is 'seq', but it can only step forwards.
>>> I know about your iter example earlier and it seems like a good fit if
>>> it starts walking in the right end?
>> Yes, 'iter' (and the related 'scan') can walk in both directions. You
>> need only to pass inverted keys (i.e. Beg > End).
>> If I understand it right, however, you solved the problem in your next
>> mail(s) by using the date index, and starting at 6 months ago?
>> - Alex
>> UNSUBSCRIBE: mailto:picol...@software-lab.de?subject=unsubscribe