estimatedEntries showing 0 in Oak Lucene query plan despite result being found | Adobe Higher Education
Skip to main content
A
Anugrah C
Level 1
March 16, 2026
解決済み

estimatedEntries showing 0 in Oak Lucene query plan despite result being found

  • March 16, 2026
  • 2 の返信
  • 40 ビュー

Hi,

I have created a custom Lucene index in AEM (damAssetLucene-13-custom-1) and when I run a query, the execution plan shows estimatedEntries: 0 even though the query successfully returns 1 result.

Execution Plan:

[dam:Asset] as [dam:Asset] /* lucene:damAssetLucene-13-custom-1
    indexDefinition: /oak:index/damAssetLucene-13-custom-1
    estimatedEntries: 0
    luceneQuery: +:ancestors:/content/dam +jcr:content/metadata/lob:lob:lls
    propertyCondition: jcr:content/metadata/lob lob:lls  */

Execution Time:

  • Total time: 1ms
  • Number of nodes in result: 1

What I have tried:

  • Reindexed the custom index (@reindex = true) — still shows estimatedEntries: 0
  • The correct index is being picked up by the query planner
  • The query returns the correct result

My understanding from Oak docs: The Apache Jackrabbit Oak documentation states "For a unique index and 'x = 1' condition, the estimated number of entries is either 0 or 1 depending on whether the key is found."

Since the result is being found (1 node returned), I would expect estimatedEntries to be 1, not 0.

Questions:

  1. Why is estimatedEntries showing 0 even though the key is found and result is returned?
  2. Does estimatedEntries: 0 indicate any issue with my custom index definition?
  3. Is there anything specific in the index definition (propertyIndex=true, analyzed, etc.) that could cause this?

Any guidance would be appreciated.

    ベストアンサー giuseppebaglio

    hi ​@Anugrah C, 

    The estimatedEntries: 0 in your execution plan is a heuristic cost metric generated by the Oak query planner before execution, not a literal count of matching documents. Your custom Lucene index is working perfectly, and this zero-cost estimation merely guarantees that the query engine selects it over less efficient alternatives.

    Your understanding of the Jackrabbit Oak documentation is correct, but the quote you referenced applies strictly to Property Indexes. Oak Property Indexes support the unique flag, allowing the estimator to accurately predict either exactly 0 or 1 entry during the planning phase. Lucene Indexes, however, use a completely different cost model based on approximations, meaning the engine will not check for exact key matches before execution.

    2 の返信

    kautuk_sahni
    Community Manager
    kautuk_sahniCommunity Manager
    Community Manager
    March 16, 2026

    ​@konstantyn_diachenko ​@Aditya_Chabuku ​@Kamal_Kishor ​@Suraj_Kamdi ​@Kiran_Vedantam Wanted to loop you in and see if you have any perspective or lessons learned that could help us here. Your insight would be helpful, thank you!

    Kautuk Sahni
    giuseppebaglio
    giuseppebaglio回答
    Level 10
    March 16, 2026

    hi ​@Anugrah C, 

    The estimatedEntries: 0 in your execution plan is a heuristic cost metric generated by the Oak query planner before execution, not a literal count of matching documents. Your custom Lucene index is working perfectly, and this zero-cost estimation merely guarantees that the query engine selects it over less efficient alternatives.

    Your understanding of the Jackrabbit Oak documentation is correct, but the quote you referenced applies strictly to Property Indexes. Oak Property Indexes support the unique flag, allowing the estimator to accurately predict either exactly 0 or 1 entry during the planning phase. Lucene Indexes, however, use a completely different cost model based on approximations, meaning the engine will not check for exact key matches before execution.

      A
      Anugrah C作成者
      Level 1
      March 16, 2026

      Hi ​@giuseppebaglio thank you for the detailed explanation!

        契約条件Accessibility statement

        Loading footer...