Parameter · Statistics / Monitoring
compute_query_id
Enables in-core computation of query identifiers.
- Default:
auto - Type: enum
- Values: auto · regress · on · off
- Applies: Session (superuser)
In plain words
A query identifier is a number that is the same for all executions of the "same" query, ignoring constant values. It lets you join what is running now (pg_stat_activity) with aggregated history (pg_stat_statements) and with log lines.
The default auto computes it only when an extension such as pg_stat_statements asks for it.
For DBAs and operators
Values: off (never), on (always), auto (default: on if a module like pg_stat_statements requests it), regress (like auto, but EXPLAIN does not print it, for stable test output). Verified on 18.6 with on:
EXPLAIN (VERBOSE, COSTS OFF) SELECT count(*) FROM tt WHERE b = 1;
Aggregate
Output: count(*)
-> Seq Scan on pg_temp.tt
…
Query Identifier: 8816725105567120267Where it shows: pg_stat_activity.query_id, EXPLAIN (VERBOSE), %Q in log_line_prefix, the query_id field in csvlog/jsonlog, and pg_stat_statements.queryid. With auto and no such module loaded, query_id is NULL and %Q prints 0.
The id is a hash of the parsed query tree with constants left out. Verified on 18.6: IN (1,2,3) and IN (1,2) now get the same id (PostgreSQL 18 squashes constant lists), and dropping and recreating a table kept the id (18 jumbles the relation name, so ids also match across sessions using temporary tables). Queries that differ only in a table alias (FROM qa x vs FROM qa y) got different ids. An external module that computes its own ids requires compute_query_id = off.
Support tip: log_line_prefix = '… %Q' plus compute_query_id = on lets you match slow-query log lines with pg_stat_statements rows.
How to change it
A superuser (or a role granted SET) can change it per session with SET.