diff options
| -rw-r--r-- | doc/src/sgml/ref/cluster.sgml | 13 |
1 files changed, 12 insertions, 1 deletions
diff --git a/doc/src/sgml/ref/cluster.sgml b/doc/src/sgml/ref/cluster.sgml index 5a2000f7bef..5492abe990c 100644 --- a/doc/src/sgml/ref/cluster.sgml +++ b/doc/src/sgml/ref/cluster.sgml @@ -1,5 +1,5 @@ <!-- -$PostgreSQL: pgsql/doc/src/sgml/ref/cluster.sgml,v 1.38 2006/11/04 19:03:51 tgl Exp $ +$PostgreSQL: pgsql/doc/src/sgml/ref/cluster.sgml,v 1.38.2.1 2007/05/13 16:04:40 mha Exp $ PostgreSQL documentation --> @@ -100,6 +100,17 @@ CLUSTER <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 table is unimportant. However, if you tend to access some |