[KinoSearch] KS 0.3007 optimize on frequent index updates/commits? Deal with out of memory?

[Ashley Pond V]

The docs are a little fuzzy on this matter -- and I think they drifted
a bit from earlier stuff. When and if should you do optimize()?

In here-

http://search.cpan.org/~creamyg/KinoSearch-0.30_07/lib/KinoSearch/Docs/Cookbook/FastUpdates.pod

-it suggests

    $indexer->optimize;    # optional
    $indexer->finish;

I think finish() is a 0.1 method, though, not a 0.3 method. So that should be-

 $indexer->optimize;
 $indexer->commit;

Right?

I have a script right now watching a database for changes and then
updating my KinoSearch index with new things when there are changes. I
was doing optimize() on it every call. Watching the index files I see
that they balloon for a moment during optimize and then settle back
down to an ideal size.

My script got an out of memory in the middle of one of these. Perhaps
because too many other things were going on so I'm not blaming KS. I
have some questions about dealing with the situation.

* Do I have to *ever* need to call optimize()? Will the index files
remain reasonable on their own over long spans of time with frequent
but small document changes and deletions?

* Is there a way to call optimize() safely? If it bombs out in the
middle it can leave a set of index files which are too big to deal
with and cause "out of memory" on any further attempts to
commit/optimize them.

This is a doc index of about 20K files and the index files occupy 80MB
after a fresh rebuild. They've crept up to 86MB doing various
adds/deletes/commits without the optimize call.

Thank you!
-Ashley