|
|
|
|
@ -1,5 +1,5 @@ |
|
|
|
|
<!-- |
|
|
|
|
$PostgreSQL: pgsql/doc/src/sgml/ref/cluster.sgml,v 1.35 2005/01/04 00:39:53 tgl Exp $ |
|
|
|
|
$PostgreSQL: pgsql/doc/src/sgml/ref/cluster.sgml,v 1.35.6.1 2007/05/13 16:04:35 mha Exp $ |
|
|
|
|
PostgreSQL documentation |
|
|
|
|
--> |
|
|
|
|
|
|
|
|
|
@ -99,6 +99,17 @@ CLUSTER |
|
|
|
|
<refsect1> |
|
|
|
|
<title>Notes</title> |
|
|
|
|
|
|
|
|
|
<para> |
|
|
|
|
<command>CLUSTER</command> loses all visibility information of tuples, |
|
|
|
|
which makes the table look empty to any snapshot that was taken |
|
|
|
|
before the <command>CLUSTER</command> command finished. That makes |
|
|
|
|
<command>CLUSTER</command> unsuitable for applications where |
|
|
|
|
transactions that access the table being clustered are run concurrently |
|
|
|
|
with <command>CLUSTER</command>. This is most visible with serializable |
|
|
|
|
transactions, because they take only one snapshot at the beginning of the |
|
|
|
|
transaction, but read-committed transactions are also affected. |
|
|
|
|
</para> |
|
|
|
|
|
|
|
|
|
<para> |
|
|
|
|
In cases where you are accessing single rows randomly |
|
|
|
|
within a table, the actual order of the data in the |
|
|
|
|
|