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 FULLna 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 CLUSTERrobi:
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 ctidkolumny, która opisuje fizyczne miejsce krotki na stronie, widać również, że nie ma przerwy w miejscu, w którym id = 5kiedyś 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 FULLnie 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.