temp_buffers
Read PG 18 manual ↗Sets the maximum amount of memory used for temporary buffers within each database session.
- Type
- integer
- Context
- user
- Measured default
- 8 MiB (1024 × 8kB)
- Unit
- 8kB
- Metadata snapshot
- 18
Definition PG 18 manual
Sets the maximum amount of memory used for temporary buffers within each database session. These are session-local buffers used only for access to temporary tables. If this value is specified without units, it is taken as blocks, that is BLCKSZ bytes, typically 8kB. The default is eight megabytes (8MB). (If BLCKSZ is not 8kB, the default value scales proportionally to it.) This setting can be changed within individual sessions, but only before the first use of temporary tables within the session; subsequent attempts to change the value will have no effect on that session.
A session will allocate temporary buffers as needed up to the limit given by temp_buffers. The cost of setting a large value in sessions that do not actually need many temporary buffers is only a buffer descriptor, or about 64 bytes, per increment in temp_buffers. However if a buffer is actually used an additional 8192 bytes will be consumed for it (or in general, BLCKSZ bytes).
Measured default history
| Version interval | Default |
|---|---|
| 9.0 – 19 | 8 MiB (1024 × 8kB) |
Authored guidance from the GUC source snapshot; the version-specific manual above is the definition reference. View source ↗
How it works
temp_buffers controls session-local buffers for temporary-table access. It does not govern sort or hash spill files created by ordinary query execution.
A session can change the value only before its first use of a temporary table; later SET commands have no effect for that session. Buffers are allocated on demand up to the ceiling.
An unused increase still creates buffer-descriptor overhead, while each buffer actually used consumes one database block, normally 8kB. Aggregate usage therefore depends on the number of sessions actively using temporary tables.
Operational considerations
Confusing temporary-table buffers with sort and hash temporary files.
Issuing SET after the session has already accessed a temporary table.
Ignoring multiplication across many sessions actively using temporary tables.
Assuming a large value is fully allocated immediately; PostgreSQL grows usage on demand, though descriptor overhead remains.
Workload guidance
OLAP: Raise it only for workflows that use PostgreSQL temporary tables; work_mem, not temp_buffers, is the primary control for sort and hash operations. Include session concurrency in the budget.
OLTP: Leave the default unless the application demonstrably uses sizable temporary tables. Prefer scoped changes in the sessions that create them and set the value before first access.
SMALL: Keep the default and avoid globally increasing per-session ceilings. Temporary-table-heavy jobs should be isolated or adjusted locally.
Version history 1
- PG 11 → 12changed
Related entries
Further reading
Definition snapshot: english-manuals:653bae76b7080c249a53fa487b7… · English manual source