compute_query_id

Definition PG 18 manual

Enables in-core computation of a query identifier. Query identifiers can be displayed in the pg_stat_activity view, using EXPLAIN, or emitted in the log if configured via the log_line_prefix parameter. The pg_stat_statements extension also requires a query identifier to be computed. Note that an external module can alternatively be used if the in-core query identifier computation method is not acceptable. In this case, in-core computation must be always disabled. Valid values are off (always disabled), on (always enabled), auto, which lets modules such as pg_stat_statements automatically enable it, and regress which has the same effect as auto, except that the query identifier is not shown in the EXPLAIN output in order to facilitate automated regression testing. The default is auto.

How it works

compute_query_id controls PostgreSQL's in-core normalized query identifier. The identifier can appear in pg_stat_activity, EXPLAIN, and logs, and is required by pg_stat_statements unless another module computes one.

auto lets a module request in-core computation, on always computes, off prevents it, and regress behaves like auto while suppressing the ID in EXPLAIN for stable regression output.

Only one provider should compute the identifier. An extension with an alternative algorithm must disable the in-core implementation and detect conflicts rather than silently publishing two incompatible IDs. Its superuser context permits an authorized session change without a server restart.

Operational considerations

Enabling the in-core provider while an extension also attempts to compute a different query identifier.

Setting off and silently losing IDs required by pg_stat_statements, logs, or correlation tooling.

Treating regress as a production optimization rather than a test-output mode.

Using query IDs as stable cross-major-version or cryptographic identifiers.

Workload guidance

OLAP: auto or on can make long analytical statements easier to correlate across pg_stat_activity, EXPLAIN, and logs. The cost is query-tree normalization and hashing, not clock reads; compare planning CPU on workloads with very large statements.

OLTP: Use auto when pg_stat_statements or another module should request the in-core identifier, and use on only when logs, EXPLAIN, or monitoring require IDs without such a module. Measure query-normalization overhead at peak parse/plan rates.

SMALL: Keep auto unless an external query-ID provider requires off. regress is for stable regression output, not a smaller production setting, and off can remove IDs required by pg_stat_statements.