Query performance

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

If the slow search is over a relationship such as groups, roles, managers, owners, or permissions, first confirm that the relationship is stored on the lower-fanout side. See Attribute Modeling before adding more index coverage.

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 for that attribute
Starts-with search	value-match is sufficient — partial-match is not required for prefixes
Contains, ends-with, or fuzzy search	partial-match; keep type scope narrow because this coverage is the most expensive to maintain
Cursor paging with orderBy	sortable for the ordered attribute
Compound filter plus sort	Both value-match and sortable where the query shape needs both

When in doubt, start with the narrowest knob that matches the actual operator mix. partial-match covers the broadest set of operators from a single attribute but costs the most disk and slows writes the most — only reach for it when callers actually issue contains, ends-with, or fuzzy searches.

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.

In an installed deployment, open Observe and use 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.

Query Diagnostic Reports include a Corpus context section when IdentityScribe can capture enough statistics for the queried entry types and attributes. Use it to confirm whether the report is based on fresh enough data, whether the affected fields have useful samples, and which replay scale support should use when comparing the report with benchmark evidence. If the section lists missing context, include the report anyway; those rows tell support which context was not available at capture time.

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