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 19e8064b172..5c63e4493c8 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.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 --> @@ -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 |