Summary

Query settings can materially change how a query executes (index hints, query framework, query knob overrides — including query stats sampling knobs), but the query stats store key (UniversalKeyComponents in src/mongo/db/query/query_stats/key.h) is derived only from the query shape and command options. Executions of the same shape with and without settings collapse into a single $queryStats entry.

Motivation

• Diagnosability. $queryStats cannot answer "which query shapes have settings applied?" or "did this shape run with my settings?". In a recent support case, a customer set setQuerySettings index hints for what they believed was one query, but their workload was actually a family of shapes (variable $or/$in clauses) with different query shape hashes — so the hint applied to some executions and not others, and nothing surfaced which shapes were covered.

• Statistical accuracy. Executions with and without settings are different populations but are aggregated into one entry, blending latency, keysExamined, etc. When settings change over time, before/after metrics silently mix, masking both regressions and the effect of the settings themselves.

• Growing exposure. SPM-4364 (in master) makes query knobs (P)QS-able — settings can now control whether and how a query is captured in query stats — and SERVER-123044 allows passing settings inline per command invocation, so two executions of the same shape can run with different settings concurrently.

• Key asymmetry. A user-supplied hint is already a key component, while the same index hint applied via (P)QS is not.

Why existing surfaces don't cover this

Slow query logs now report applied querySettings and knob overrides, and shards report originalQueryShapeHash; SERVER-116447 tracks currentOp and profiler. But these are per-execution, threshold/sampling-gated records — not the always-on, pre-aggregated view that $queryStats provides for questions like "which shapes are covered, and how do their stats compare?".

Proposed solution

Add the resolved query settings (or a digest of them) to UniversalKeyComponents — the key becomes (query shape, applied settings). Benefits: entries cleanly separate executions with settings from those without; metrics are no longer mixed across populations; settings coverage is auditable at a glance.

Acceptance criteria

• $queryStats output distinguishes entries that ran with query settings from those that did not, and reports the applied settings.
• Representative query output remains self-describing.
• Behavior documented and covered by unit + jstests.

Related

• PM-412 — query settings (P)QS
• SPM-4364 — query knob overrides via query settings
• SERVER-123044 — per-command query settings
• SERVER-116447 — expose querySettings in currentOp / profiler
• SERVER-80421 — earlier duplicate of this request