tmvlad opened a new pull request, #3131: URL: https://github.com/apache/jackrabbit-oak/pull/3131
## Problem For a Lucene/Elastic property index, the planner estimated a path-restricted query's entry count as a flat fraction of the index's *global* doc count (DIRECT_CHILDREN → /2, ALL_CHILDREN → *0.9), ignoring the actual subtree. So ISCHILDNODE was always ~55% of ISDESCENDANTNODE regardless of tree shape, and on wide/deep folders (few child folders, many descendant assets) the estimate stayed near the whole-index size. Traversal is costed from the real subtree size (node counter) and DIRECT_CHILDREN is never subtree-scaled in the query engine, so the inflated index estimate exceeded the traversal cost and Oak traversed (slowly). ## Fix Estimate the path-restricted count from the index itself: count docs matching `:ancestors:<path>` (descendants) or `:ancestors:<path>` AND `:depth=<childDepth>` (direct children) — the same predicate the query runs, relativized like `FulltextIndex#getPathRestriction` — capped at the property estimate. Behind the default-on `FT_OAK-12401` kill-switch; falls back to the legacy heuristic when disabled. New SPI `IndexStatistics#getDocCountForPath`; Lucene via the searcher (`docFreq` for descendants, a count for the `:ancestors`+`:depth` conjunction), Elastic via the cached `getDocCountFor(Query)`. ## Verification Unit test (500 global matches + a `/test` subtree of 5 direct children / 50 descendants, property estimate 110): | | before | after | |---|---|---| | ISCHILDNODE | 55 (=110/2) | 5 | | ISDESCENDANTNODE | 99 (=110*0.9) | 50 | Both backends green (`IndexPathRestrictionCommonTest`, Lucene + Elastic incl. a subtree-mounted regression test). Legacy behaviour covered via a toggle-disabled test. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
