CLUSTER 指示 PostgreSQL 基于索引 indexname 的度量对表 tablename 进行存储群集。索引必须已经在表 tablename 上定义。
当对一个表群集后，该表的物理存储将基于索引信息进行。群集是一次性操作：当表将来被更新之后，更改的内容不会被群集。也就是说，系统不会试图按照索引顺序对更新过的记录重新群集。如果需要，可以通过周期性地手工执行该命令的方法重新群集。
在对一个表群集之后，PostgreSQL 会记忆在哪个索引上建立了群集。CLUSTER tablename 的形式就在表以前群集的同一个索引上重新群集。
没有任何参数的 CLUSTER 将导致当前数据库里调用用户的所有表都被群集(如果是超级用户的话则所有表都被群集)，不过不包括禁止群集的表。这种形式的 CLUSTER 不能在一个事务或者函数里面调用。
在对一个表进行群集的时候，会在其上请求一个 ACCESS EXCLUSIVE 锁。这样就避免了在 CLUSTER 完成之前执行任何其它的数据库操作(包括读写)。
如果你只是随机的访问表中的行，那么表中数据的实际存储顺序是无关紧要的。但是，如果对某些数据的访问多于其它数据，而且有一个索引将这些数据分组，那么将从使用 CLUSTER 中获益。如果从一个表中请求一定索引范围的值，或者是一个索引值对应多行，CLUSTER 也会有助于应用，因为如果索引标识出第一匹配行所在的存储页，所有其它行也可能已经在同一个存储页里了，这样便节省了磁盘访问的时间，加速了查询。
在这个群集的操作过程中，系统先创建一个按照索引顺序建立的表的临时拷贝。同时也建立表上的每个索引的临时拷贝。因此，需要磁盘上有足够的剩余空间，至少是表大小和索引大小的和。
因为 CLUSTER 记忆群集信息，可以在第一次的时候手工对表进行群集，然后设置一个类似 VACUUM 的时间，这样就可以周期地自动对表进行群集操作。
因为规划器记录着有关表的排序的统计，所以建议在新近群集的表上运行 ANALYZE 。否则，规划器可能会选择很差劲的查询规划。
还有另外一种群集数据的方法。CLUSTER 命令将原表按你声明的索引重新排列。这个动作在操作大表时可能会很慢，因为每一行都按索引顺序取出，所以如果表没有排序，那么整个表就是随机存放在各个页面里的，因而每移动一行都要进行一次磁盘页面操作。PostgreSQL 有一个缓冲，但一个大表的主体是不可能都放到缓冲去的。这种对表群集的另外方法是
CREATE TABLE newtable AS
SELECT * FROM table ORDER BY columnlist;
这个用法使用排序代码来创建一个需要的顺序，在对未排序的数据操作时速度通常比索引扫描快得多。然后你可以删除旧表，用 ALTER TABLE ... RENAME 将 newtable 改成旧表名，并且重建该表的所有索引。但是，这个方法不保留 OID 、约束、外键关系、赋予的权限、以及其它附属的属性，所有这些属性都必须手工重建。令一个不利之处是这种方法需要一个与原表大小相同的临时排序文件，所以所需磁盘空间将三倍于原表大小。