Aby to sprawdzić CLUSTER
, wziąłem tabelę z mojego wcześniejszego eksperymentu, która zawierała pierwsze 10 milionów dodatnich liczb całkowitych. Usunąłem już niektóre wiersze i jest też inna kolumna, ale wpływają one tylko na rzeczywisty rozmiar tabeli, więc nie jest to takie interesujące.
Po pierwsze, po uruchomieniu VACUUM FULL
na stole fka
, wziąłem jego rozmiar:
\dt+ fka
List of relations
Schema | Name | Type | Owner | Size | Description
--------+------+-------+----------+--------+-------------
public | fka | table | test | 338 MB |
Zobaczmy więc fizyczną kolejność danych od samego początku tabeli:
SELECT *, ctid FROM fka ORDER BY ctid LIMIT 5;
id | col1 | ctid
-----+------+---------
2 | 2 | (0,1)
3 | 3 | (0,2)
4 | 4 | (0,3)
5 | 5 | (0,4)
6 | 6 | (0,5)
Teraz usuńmy niektóre wiersze:
DELETE FROM fka WHERE id % 10 = 5;
--DELETE 1000000
Po tym raportowany rozmiar tabeli nie zmienił się. Zobaczmy teraz, co CLUSTER
robi:
CLUSTER fka USING fka_pkey;
SELECT *, ctid FROM fka ORDER BY ctid LIMIT 5;
id | col1 | ctid
-----+------+---------
2 | 2 | (0,1)
3 | 3 | (0,2)
4 | 4 | (0,3)
6 | 6 | (0,4)
7 | 7 | (0,5)
Po operacji rozmiar tabeli zmienił się z 338 na 296 MB. Z ctid
kolumny, która opisuje fizyczne miejsce krotki na stronie, widać również, że nie ma przerwy w miejscu, w którym id = 5
kiedyś było dopasowanie wierszy .
Po zmianie kolejności krotek indeksy powinny zostać odtworzone, aby wskazywały właściwe miejsca.
Różnica wygląda na to, że VACUUM FULL
nie porządkuje wierszy. O ile mi wiadomo, istnieje pewna różnica w mechanizmie używanym przez te dwa polecenia, ale z praktycznego punktu widzenia wydaje się, że jest to główna (jedyna?) Różnica.