Hi Team, Currently in case large deletion are performed i.e. deleting big subtree where multiple property indexes are configured for nodes in that deleted tree then deletion is found to be very slow (at least for DocumentMK).
Looking at the code it seems that if a deletion is detected the editor still traverses the deleted sub tree completely and updates the backing index on per node basis. Instead of that if it utilizes the fact that index is also managed as a tree i.e. at least for ContentMirrorStoreStrategy it can just delete the index tree at that path for various values. LuceneIndexEditor takes a similar approach [1] by issuing a PrefixQuery to drop all Lucene documents under that path Chetan Mehrotra [1] https://github.com/apache/jackrabbit-oak/blob/trunk/oak-lucene/src/main/java/org/apache/jackrabbit/oak/plugins/index/lucene/LuceneIndexEditor.java#L230-255