tmvlad opened a new pull request, #3128: URL: https://github.com/apache/jackrabbit-oak/pull/3128
## Problem Queries that combine a nodeName condition (SQL2 `NAME(node) = 'x'` / xpath `fn:name()`, which the query engine turns into the `:localname` filter restriction, matched against the index's `:nodeName` field) OR'd with property restrictions run inefficiently. The shared `FulltextIndexPlanner` did not take the nodeName condition into account when estimating index cost. As a result the reported cost was unrealistically high, so the property/nodeName filters were not pushed down to the index — only the ancestor/path filter was applied and the rest of the condition was evaluated by traversal. Because the cost estimation lives in the shared `oak-search` planner, both Lucene and Elastic are affected. ## Fix When the filter has a nodeName (`:localname`) restriction that the index can evaluate (`canEvalNodeNameRestriction`), its selectivity is now accounted for in cost estimation, treating it like a default-weight indexed property. The `:nodeName` field is not a regular property field (it starts with `:`), so it has no per-field statistics and is never part of `propDefns`. The estimate therefore uses `numDocs` scaled by `DEFAULT_PROPERTY_WEIGHT`, with the weight capped at 3 for a non-equality (LIKE) restriction — mirroring how regular properties are handled. The change is applied to both cost paths: the default `getMaxPossibleNumDocs` and the feature-flagged selectivity model. ## Tests Added `IndexPlannerTest` cases covering nodeName cost estimation across: - both cost paths (default and selectivity model), - EQUAL and LIKE operators, and - nodeName alone vs combined with a property restriction. Each new test was confirmed to fail without the production change. The full `IndexPlannerTest` (87) and `oak-search` (164) suites pass, and `LucenePropertyIndexTest` shows no regressions. -- 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]
