Parameter · Statistics / Cumulative Query and Index Statistics
stats_fetch_consistency
Sets the consistency of accesses to statistics data.
- Default:
cache - Type: enum
- Values: none · cache · snapshot
- Applies: Session (any user)
In plain words
The statistics views are fed from shared memory that changes all the time. This setting decides what you see when you read them several times inside one transaction: always the latest numbers (none), the same numbers for an object you already looked at (cache, default), or one frozen picture of everything (snapshot).
For DBAs and operators
Added in PostgreSQL 15, when the statistics collector process was replaced by shared memory.
none: every access fetches from shared memory. Cheapest; ideal for monitoring tools that read each counter once per poll.cache(default): the first access to an object's stats caches them until the end of the transaction orpg_stat_clear_snapshot(). A self-join of a stats view gives consistent results.snapshot: the first access caches all stats of the current database. Consistent across objects, useful for interactive investigation, but costly with many objects.
Changing the setting inside a transaction discards the current snapshot. Only cumulative statistics are affected. pg_stat_activity (and the progress views, which read the same backend status) follows its own rule whatever this setting says: the first read in a transaction takes a copy that is kept until the transaction ends or pg_stat_clear_snapshot() is called. Verified on 18.6: even with none, a second read in the same transaction still showed another session's previous query.
Classic confusion: in an open transaction (or a tool that wraps everything in one), a monitoring query keeps returning the same n_tup_ins while the table is obviously growing. Call pg_stat_clear_snapshot(), commit, or use none (for pg_stat_activity only the first two help).
How to change it
Any user can change it for their session with SET.