Why not load SearchIndex from cache on delete/vacuum and Writer BGW?

[softhuafei]

What would you like to discuss?

I have observed that when scanning and inserting, we get the SearchIndex from the cache, but in delete/vacuum, it is loaded from disk. Also, when the writer BGW gets the indexwriter, it is also loaded from disk. Why not use the cache in the latter two cases?

Writer::insert()/delete()/vacuum()
 ->Writer::get_writer()
    -> SearchIndex::writer()

here, load index will call tantivy::index::open_dir() and load tantivy::Index::reader_builder(). tantivy::index::open_dir() is usually very fast, but tantivy::Index::reader_builder() is very slow when there are many tantivy segments.

In general, I have two questions:

1. Why not use SearchIndex Cache on these links? Especially when getting IndexWriter.
2. Why not initialize the reader when needed, instead of initializing the reader at the same time every time the index is loaded, so as to save extra overhead on the write.

Full Name:

Zhiwei Wu

Affiliation:

None

[neilyio]

@softhuafei, thank you for taking the time to review our codebase! We always appreciate suggestions for performance improvements. While you're correct that there's overhead to loading the index reader/writer from disk, I think in this case the impact is negligible.

Operations that mutate the index are only ever performed from the dedicated background writer process (you can see how it's initialized in lib.rs), and the writer instance is cached in memory after being loaded. The cost of initializing the writer is only paid once.

The design of the background writer process currently only allows a single connection to mutate a writer at a time. We are working to change this to make concurrent writes possible, and that will require more sophisticated loading/unloading of writer instances. When that time comes I think your observation will be relevant, and we will make sure the writer initialization is optimized.