Oak Index Studio
/oak:index — query → lucene definition
/analysis
Node type
cq:Page
Path restriction
/content/wknd
/analysis/health
Overall score
100/100
- includedPaths (index root) ✓
includedPaths (/content/wknd) scopes the index to specific content — good.
- queryPaths (index root) ✓
queryPaths matches includedPaths — good.
- ordered (all properties) ✓
ordered=true properties detected — this alone is sufficient for ORDER BY (doc-values sorting); propertyIndex is only needed if the property is also filtered in a WHERE clause.
- property types (all properties) ✓
No obviously mistyped properties detected.
- propertyIndex (all properties) ✓
Every property definition has at least one capability flag set — good.
- analyzed (none) ✓
No analyzed properties.
- nodeScopeIndex (all properties) ✓
nodeScopeIndex usage is consistent — always paired with analyzed.
- evaluatePathRestrictions (index root) ✓
evaluatePathRestrictions=true — good.
- null checks (all properties) ✓
No nullCheckEnabled properties — good.
- regex (all properties) ✓
No regex-based property definitions — good.
- tags (index root) ✓
No index tag set — fine unless Oak is currently selecting the wrong index for this query.
- selectionPolicy (index root) ✓
No selectionPolicy set — Oak's default cost-based selection applies.
- compatVersion (index root) ✓
compatVersion=2 — good.
- async (index root) ✓
async=["async","nrt"] — async with near-real-time visibility, good.
/analysis/performance-estimate
Estimated complexity
Low(29/100 heuristic)
Relative cost heuristic (arbitrary scale — not Oak's cost=X)
~14–41
Confidence
65/100
Reduced from a 70-point ceiling (this tool never claims high confidence) for: 1 range predicate(s) of unknown width.
- Index selectivity [medium]
Best-case selectivity across 2 properties: moderate. Oak evaluates ANDed conditions by intersecting, so the single most selective predicate dominates.
Assumption: Selectivity is derived only from operator type (=, range, LIKE, IS NULL, ...) combined with the guessed cardinality above — never from actual value distribution.
- Property cardinality assumptions [low]
jcr:content/cq:template: low (~10-50 values assumed); jcr:content/cq:lastModified: high (near-continuous)
Assumption: Cardinality is guessed from property name and declared type only (Boolean → 2 values, Date → near-continuous, enum-like names → ~10-50 values, everything else defaults to an unverified 'medium' guess).
- Range predicate impact [medium]
1 range predicate(s) on jcr:content/cq:lastModified. Cost scales with how much of the value space each interval covers.
Assumption: This parser can't tell a tightly-bounded range (e.g. a single day) from a wide-open one (e.g. 'after 2020') from the query text — assumed 'moderate, unknown width' for every range predicate found.
- Join cost [low]
No JOIN — zero join cost.
Assumption: N/A — single-selector query.
- Sorting cost [low]
ORDER BY on 1 property. A single ordered property can be pre-sorted by lucene cheaply; multiple properties typically fall back to an in-memory sort of the full result set.
Assumption: Assumes the generated index defines ordered=true on the sorted properties (as this app's own generator does) — if it doesn't, sorting cost is worse than estimated here.
- Path restriction effectiveness [medium]
Scoped path(s) (/content/wknd, depth 2). Deeper paths are assumed to narrow the candidate set more.
Assumption: Heuristic only: path depth is used as a rough proxy for 'how much of the repository this excludes' — this tool has no actual knowledge of how content is distributed under that path.
Assumptions behind this estimate
- This estimator has no access to the real repository, its content, or Oak's actual index statistics — every number below is a relative heuristic for comparing queries, not a prediction of real query time.
- Property cardinality (how many distinct values a property has) is guessed from its name and declared type, never measured against real data.
- Range predicate width (how much of the value space a >, <, or BETWEEN-style condition actually covers) can't be determined from the query text alone.
- Join cost assumes Oak's documented per-selector-independent-then-merge execution model; the real cost depends on each selector's actual result-set size, which is unknown here.
- jcr:content/cq:template's name suggests an enum-like field (status/type/template/tag/...) — assumed roughly 10-50 distinct values, not measured.
- jcr:content/cq:lastModified is a Date — assumed near-continuous distinct values, so exact-value equality is expected to be highly selective (range comparisons are assessed separately).
All figures on this page are heuristic estimates derived from the query's shape alone, on an arbitrary 0-100 scale — they are NOT Oak's real cost() values, and are not expressed in Oak's costPerEntry/costPerExecution units. Oak's actual cost is computed from real entryCount statistics in the live repository (cost ≈ entryCount × costPerEntry + costPerExecution), which this tool has no access to and therefore cannot emulate. Always verify with an actual Explain Query (cost=X) against the target repository before drawing conclusions.
/analysis/properties
| property | ops | type | flags |
|---|---|---|---|
| jcr:content/cq:template | = | String | |
| jcr:content/cq:lastModified | range,order | Date | ordered |
/analysis/reasoning
- index root type=lucene / compatVersion=2
Lucene compat 2 is the only index type supporting the combination of property, ordered, analyzed and facet definitions in one index; required on AEMaaCS.
- index root async=["async","nrt"]
Async + NRT: near-real-time updates between async cycles, standard for AEMaaCS.
- index root includedPaths=["/content/wknd"]
Only content under the query's path restriction is indexed — smaller index, faster reindex.
- index root evaluatePathRestrictions=true
Stores :ancestors so ISDESCENDANTNODE / path= is evaluated inside lucene instead of post-filtering every hit.
- index root queryPaths
Tells the query engine this index only answers queries under these paths — prevents wrong index selection for unrelated queries.
- jcr:content/cq:template propertyIndex=true
Query filters on this property (=) — without propertyIndex the value is not stored for lookup and the condition would be post-filtered.
- jcr:content/cq:lastModified propertyIndex=true
Query filters on this property (range) — without propertyIndex the value is not stored for lookup and the condition would be post-filtered.
- jcr:content/cq:lastModified ordered=true
Range comparison (>, <, BETWEEN, daterange) needs ordered storage to seek instead of scanning all values.
- jcr:content/cq:lastModified type=Date
Value/format in the query implies Date; typed storage makes range comparison and ordering correct (string-ordered dates/numbers sort wrongly).
- index root indexRules/cq:Page
Rule scoped to cq:Page — only nodes of this type (and subtypes) are indexed, keeping the index minimal.
/analysis/selectors
Selector
p
Type
cq:Page
Path restriction
/content/wknd
Properties
p
- jcr:content/cq:template
- jcr:content/cq:lastModified
Order by
p.jcr:content/cq:lastModified ↓
/oak:index/cqPageLucene-custom-1
/warnings
No warnings.
/suggestions
- cq:Page already has a substantial OOTB Lucene index (/oak:index/cqPageLucene). Before deploying this generated definition as a wholly separate index, check whether your project already has a cqPageLucene-custom-N copy and add these property definitions there instead — two independent indexes covering the same node type roughly doubles write-time indexing overhead for every cq:Page change. Never edit /oak:index/cqPageLucene itself (product updates can overwrite it) — a -custom-N copy, which is exactly the naming this tool already generates on AEMaaCS, is the correct way to extend it.
- AEMaaCS naming: 'cqPageLucene-custom-1' follows the required <name>-custom-<version> convention; deploy under /oak:index in ui.apps — Cloud Manager triggers reindexing automatically. Never set reindex=true in the package on AEMaaCS.
- Deliberately omitted: tags, selectionPolicy, costPerEntry/costPerExecution. Add an index tag + option(index tag ...) only if Oak picks the wrong index; cost overrides are a last resort and mask real problems.
/performance
Heuristic estimate from static analysis. Real cost depends on repository size and index statistics — verify with Explain Query after deployment.