Partycjonowanie (ang. partitioning) to podział jednej dużej tabeli (albo indeksu) na mniejsze, zarządzane osobno fragmenty — partycje — według ustalonego klucza, najczęściej daty, zakresu liczb albo wartości listy. Z punktu widzenia aplikacji i Twojego SELECT nadal jest to jedna tabela: piszesz do niej i czytasz tak samo. Pod spodem silnik bazy trzyma dane w odrębnych kawałkach, co pozwala czytać i obsługiwać tylko te, które naprawdę są potrzebne.
Po co to robić
Główny zysk to partition pruning — gdy w zapytaniu pojawia się warunek na kluczu partycjonowania, baza pomija partycje, które na pewno nie zawierają wyników. Zamiast skanować 500 milionów wierszy, dotykasz tylko jednej partycji z marca. To różnica między kawą a obiadem, jeśli chodzi o czas oczekiwania.
Drugi zysk jest operacyjny. Usunięcie starych danych to nie ciągnący się godzinami DELETE zarzynający bazę, tylko jeden DROP PARTITION — natychmiastowy i bez puchnięcia loga transakcji. Łatwiej też archiwizować, backupować pojedyncze okresy i utrzymywać mniejsze, zdrowsze indeksy.
Typy podziału
- RANGE — po zakresach, klasyk dla dat (każdy miesiąc to partycja).
- LIST — po wartościach z listy, np. region czy kraj.
- HASH — równomierne rozrzucenie po N koszykach, gdy nie ma naturalnego zakresu.
Przykład z praktyki
W PostgreSQL tworzysz tabelę nadrzędną i dokładasz partycje na konkretne miesiące:
CREATE TABLE zdarzenia (id bigint, ts timestamptz, payload jsonb) PARTITION BY RANGE (ts);
CREATE TABLE zdarzenia_2026_06 PARTITION OF zdarzenia FOR VALUES FROM ('2026-06-01') TO ('2026-07-01');
Od PostgreSQL 10 masz partycjonowanie deklaratywne, więc nie musisz już bawić się w triggery i dziedziczenie jak za dawnych lat. Tworzenie nowych partycji co miesiąc warto zautomatyzować — np. rozszerzeniem pg_partman albo cronem.
Na co uważać
Najczęstszy błąd to mylenie partycjonowania z shardingiem. Partycje zwykle leżą na jednym serwerze — to organizacja danych, a nie skalowanie poziome na wiele maszyn. Drugi grzech: jeśli zapytanie nie filtruje po kluczu partycjonowania, baza i tak przejedzie wszystkie partycje, a Ty dostajesz narzut zamiast zysku. Wybór klucza to decyzja na lata, więc dobierz go do realnych WHERE. I pamiętaj, że klucz partycjonowania musi wejść w skład klucza głównego oraz indeksów unikalnych.
Pojęcia powiązane: indeksy, sharding, partition pruning, replikacja, pg_partman, hurtownie danych, klucz główny.