*** doc/src/sgml/failover.sgml	2006-11-15 08:58:34.000000000 +0100
--- doc/src/sgml/failover.sgml	2006-11-15 09:10:53.000000000 +0100
***************
*** 114,150 ****
    </para>
   </sect1>
  
-  <sect1 id="data-partitioning">
-   <title>Data Partitioning</title>
- 
-   <para>
-    Data partitioning splits tables into data sets.  Each set can only be
-    modified by one server.  For example, data can be partitioned by
-    offices, e.g. London and Paris.  While London and Paris servers have all
-    data records, only London can modify London records, and Paris can only
-    modify Paris records.
-   </para>
- 
-   <para>
-    Such partitioning provides both failover and load balancing.  Failover
-    is achieved because the data resides on both servers, and this is an
-    ideal way to enable failover if the servers share a slow communication
-    channel. Load balancing is possible because read requests can go to any
-    of the servers, and write requests are split among the servers.  Of
-    course, the communication to keep all the servers up-to-date adds
-    overhead, so ideally the write load should be low, or localized as in
-    the London/Paris example above.
-   </para>
- 
-   <para>
-    Data partitioning is usually handled by application code, though rules
-    and triggers can be used to keep the read-only data sets current.  Slony-I
-    can also be used in such a setup.  While Slony-I replicates only entire
-    tables, London and Paris can be placed in separate tables, and
-    inheritance can be used to access both tables using a single table name.
-   </para>
-  </sect1>
- 
   <sect1 id="query-broadcast-load-balancing">
    <title>Query Broadcast Load Balancing</title>
  
--- 114,119 ----
***************
*** 198,203 ****
--- 167,203 ----
    </para>
   </sect1>
  
+  <sect1 id="data-partitioning">
+   <title>Data Partitioning</title>
+ 
+   <para>
+    Data partitioning splits tables into data sets.  Each set can only be
+    modified by one server.  For example, data can be partitioned by
+    offices, e.g. London and Paris.  While London and Paris servers have all
+    data records, only London can modify London records, and Paris can only
+    modify Paris records.
+   </para>
+ 
+   <para>
+    Such partitioning provides both failover and load balancing.  Failover
+    is achieved because the data resides on both servers, and this is an
+    ideal way to enable failover if the servers share a slow communication
+    channel. Load balancing is possible because read requests can go to any
+    of the servers, and write requests are split among the servers.  Of
+    course, the communication to keep all the servers up-to-date adds
+    overhead, so ideally the write load should be low, or localized as in
+    the London/Paris example above.
+   </para>
+ 
+   <para>
+    Data partitioning is usually handled by application code, though rules
+    and triggers can be used to keep the read-only data sets current.  Slony-I
+    can also be used in such a setup.  While Slony-I replicates only entire
+    tables, London and Paris can be placed in separate tables, and
+    inheritance can be used to access both tables using a single table name.
+   </para>
+  </sect1>
+ 
   <sect1 id="clustering-for-parallel-query-execution">
    <title>Clustering For Parallel Query Execution</title>