Query performance

Use this page when a client search is slow or shows up in Observe slow-query insights.

Prefer exact equality filters over substring filters when the caller has an exact value. Drop orderBy when the client does not need deterministic ordering, and request only attributes the caller renders. REST and generated GraphQL entry types are type-scoped by construction; dynamic base-DN callers should keep the base as narrow as the workflow allows.

Query shape	Preferred coverage
Exact lookup on one attribute	value-match coverage for that attribute
Cursor paging with orderBy	sortable coverage for the ordered attribute
Prefix or contains search	partial-match coverage; keep type scope narrow
Compound filter plus sort	Both value-match and sortable coverage where the query shape needs both

Index coverage is configured with the root indices.* defaults or, when one entry type needs different coverage, with that transcribe’s indices block. See the Indices reference and Transcribes reference for the exact keys and environment variables.

Only add attributes that your callers actually search or sort on. Extra coverage increases write cost and disk usage.

Use Observe -> Indexes -> Stats to check whether the affected attribute has the expected index coverage and whether those indexes are being used. Inbox recommendations describe the slow query shape and the customer-facing configuration to review. If the right action is not clear, send the slow-query report to Kenoxa support so we can recommend a safe tuning change.

For server-side memory and PostgreSQL session settings, use Database tuning.