>> Are there plans to add timestamps to the database?
>> UNIX time since epoch would be enough...
>> Any hints?
>Well, I see one potentially confusing problem with that. As the index
becomes outdated, the
>timestamps will become outdated as well. This may or may not be a
problem, of course.
I could life with this. If you update your index file with cron at
midnight and move documents
before midnight the index will be inconsistent too.
The problem of inconsistency can only be solved by generating the index at
>I don't see any trouble with the search script gathering timestamps from
the filesystem. It
>really isn't a speed or technical issue as it is fast and simple. My
search results rarely
>takes more than 30 - 50 milliseconds to generate results while reading
>including timestamp and various metadata fields, from the file system. I
consider that a bit
>slow however not unreasonable.
However it becomes more important if your server hardware is not that
>This would be useful if the files aren't locally stored, though. HTTP
I/O has tremendous
>latency. If you're willing to have a few incorrect modification dates,
then it would be useful.
>A problem I see with adding this and that to the index; when does the
index file begin to
>approach or exceed the total size of the files indexed? If everything is
in the index, then why
>even have them in the file system. Convenience?
:-) You are right. But it would not need more space than the file size
I think this would not blow the index that much. And if the index is
stored at a different location
and filesystem access is not possible this would be the only chance to get
It seems that you don't like the idea... but maybe you give it a try if
you're out of ideas :-)
Received on Tue Aug 24 01:03:29 1999