Tablespaces

Was Postgres bei der Installation mitbringt

Jeder Postgres-Cluster hat von Haus aus zwei Tablespaces:

Ohne weiteres Zutun landet alles in pg_default.

Eigenen Tablespace anlegen

CREATE TABLESPACE fast_ssd
    OWNER app_owner
    LOCATION '/mnt/nvme/postgres';

Voraussetzungen:

• Das Verzeichnis muss vor dem Befehl existieren.
• Es muss dem Postgres-OS-User gehören (chown postgres:postgres).
• Es muss leer sein.
• Postgres muss als Superuser arbeiten — CREATE TABLESPACE ist Superuser-only.

Objekte in einem Tablespace ablegen

Beim Erstellen explizit angeben:

CREATE TABLE big_log (
    id    bigserial primary key,
    data  jsonb
) TABLESPACE fast_ssd;

CREATE INDEX big_log_data_idx ON big_log USING gin (data) TABLESPACE fast_ssd;

Bestehende Tabellen umziehen:

ALTER TABLE big_log SET TABLESPACE fast_ssd;
ALTER INDEX big_log_data_idx SET TABLESPACE fast_ssd;

ALTER TABLE … SET TABLESPACE kopiert die Daten physisch und nimmt einen ACCESS EXCLUSIVE-Lock auf die Tabelle — bei großen Tabellen kann das lange dauern und die Anwendung blockieren. Nicht in Stoßzeiten machen.

Default-Tablespace pro Datenbank festlegen:

ALTER DATABASE myapp SET TABLESPACE fast_ssd;

Wann lohnen sich Tablespaces?

Klassische Use Cases:

1. Heiße vs. kalte Daten trennen. Aktuelle Logs auf NVMe-SSD, Archiv-Daten auf langsameren HDDs.
2. Indexe auf separate Disks. Reduziert I/O-Konkurrenz zwischen Heap-Reads und Index-Reads.
3. Speichergrenzen pro Datenträger umgehen. Wenn ein Volume voll ist, einen weiteren mounten und neue Tabellen darauf legen.
4. Performance-Isolation pro Tenant. In Multi-Tenant-Setups einen Tenant auf eine eigene Disk legen.

Aber: vieles davon ist heute weniger relevant als früher. Moderne SSDs sind so schnell, dass die I/O-Konkurrenz, die in den 2000ern durch separate Disks aufgelöst wurde, heute oft kein Problem mehr ist. Wer kann, lässt erst mal alles in pg_default und tunt erst, wenn ein konkreter Engpass nachweisbar ist.

temp_tablespaces

Für temporäre Objekte (Sort-Spill, Hash-Spill bei großen Joins, temporäre Tabellen) gibt es einen Sonderparameter:

temp_tablespaces = 'temp_fast'

Sinn: ein eigenes Volume für I/O-intensive temporäre Operationen. Auf einer SSD-only-Installation lohnt sich das selten; auf gemischten Setups kann es größere ORDER BYs deutlich beschleunigen, wenn der Sort nicht in den work_mem passt.

Tablespace droppen

DROP TABLESPACE fast_ssd;

Postgres lehnt ab, solange der Tablespace noch Objekte enthält. Erst alle Tabellen / Indexe in einen anderen Tablespace verschieben oder droppen, dann löst sich DROP TABLESPACE.

Inspektion

myapp=# \db+
                          List of tablespaces
    Name    |  Owner   |    Location     | Access privileges | Size
------------+----------+-----------------+-------------------+-------
 pg_default | postgres |                 |                   | 128 MB
 pg_global  | postgres |                 |                   | 612 KB
 fast_ssd   | postgres | /mnt/nvme/pg    |                   | 0 B

pg_default und pg_global haben keinen LOCATION — sie liegen innerhalb des PGDATA-Verzeichnisses.

Zu welchem Tablespace gehört eine Tabelle?

SELECT c.relname,
       COALESCE(t.spcname, 'pg_default') AS tablespace
FROM pg_class c
LEFT JOIN pg_tablespace t ON t.oid = c.reltablespace
WHERE c.relkind = 'r' AND c.relname = 'big_log';

Wenn reltablespace = 0, gehört die Tabelle zum Default-Tablespace der Datenbank.

Weiterführende Ressourcen

Externe Quellen

• Tablespaces – PostgreSQL Documentation
• CREATE TABLESPACE – PostgreSQL Documentation
• ALTER TABLE … SET TABLESPACE
• pg_basebackup —tablespace-mapping
• temp_tablespaces – Run-time Configuration

Verwandte Artikel

• Architektur-Überblick: Prozessmodell, WAL, MVCC
• Konfigurationsdateien
• Datenbank-Encoding und Collation