temp_tablespaces

Definition PG 18 manual

This variable specifies tablespaces in which to create temporary objects (temp tables and indexes on temp tables) when a CREATE command does not explicitly specify a tablespace. Temporary files for purposes such as sorting large data sets are also created in these tablespaces.

The value is a list of names of tablespaces. When there is more than one name in the list, PostgreSQL chooses a random member of the list each time a temporary object is to be created; except that within a transaction, successively created temporary objects are placed in successive tablespaces from the list. If the selected element of the list is an empty string, PostgreSQL will automatically use the default tablespace of the current database instead.

When temp_tablespaces is set interactively, specifying a nonexistent tablespace is an error, as is specifying a tablespace for which the user does not have CREATE privilege. However, when using a previously set value, nonexistent tablespaces are ignored, as are tablespaces for which the user lacks CREATE privilege. In particular, this rule applies when using a value set in postgresql.conf.

The default value is an empty string, which results in all temporary objects being created in the default tablespace of the current database.

See also default_tablespace.

How it works

temp_tablespaces sets the tablespace(s) to use for temporary tables and sort files. An empty string means use the database's default tablespace. PostgreSQL uses the list for temporary relations and executor spill files, choosing among multiple entries to distribute work; permissions and existence are checked by context.

temp_tablespaces is a USER-context setting. An authorized role can change it for a session, while ALTER ROLE or ALTER DATABASE can establish a default for future sessions.

It supplies a default only when SQL omits an explicit choice, so schema migrations, object-level options, privileges, and later ALTER operations can override or outlive it.

Operational considerations

Changing temp_tablespaces in one session and assuming role defaults, database defaults, or other pooled sessions changed with it.

Expecting a changed default to rewrite existing objects or override explicit DDL clauses.

Ignoring tablespace privileges, installed access methods or compression support, and restore portability.

Changing temp_tablespaces globally without a rollback plan and a client or operational compatibility test.

Workload guidance

OLAP: Use temp_tablespaces deliberately for bulk objects and spill-heavy jobs, checking I/O placement, compression support, and operational tooling before adoption.

OLTP: Keep temp_tablespaces aligned with schema-management policy and make important storage choices explicit in migrations. Benchmark any physical-layout change with production-shaped writes.

SMALL: Prefer the upstream default for temp_tablespaces unless the node has a verified alternate storage path or restore requirement; simplicity reduces recovery surprises.