diff --git a/reference/en/modules/collection_mapping.xml b/reference/en/modules/collection_mapping.xml
index aa9ac4307a..e86c38d755 100644
--- a/reference/en/modules/collection_mapping.xml
+++ b/reference/en/modules/collection_mapping.xml
@@ -198,8 +198,7 @@ kittens = cat.getKittens(); // Okay, kittens collection is a Set
                     <para>
                         <literal>fetch</literal> (optional, defaults to <literal>select</literal>) Choose
                         between outer-join fetching, fetching by sequential select, and fetching by sequential
-                        subselect. Only one collection may be fetched by outer join per SQL 
-                        <literal>SELECT</literal>.
+                        subselect.
                     </para>
                 </callout>
                 <callout arearefs="mappingcollection11">
diff --git a/reference/en/modules/performance.xml b/reference/en/modules/performance.xml
index 0b4ae67d43..db31be0827 100644
--- a/reference/en/modules/performance.xml
+++ b/reference/en/modules/performance.xml
@@ -217,26 +217,6 @@ Integer accessLevel = (Integer) permissions.get("accounts");  // Error!]]></prog
             <para>
                 (This is Hibernate's equivalent of what some ORM solutions call a "fetch plan".)
             </para>
-   
-            <para>
-                Join fetching for collections has one limitation: you may only set one collection 
-                role per persistent class or query to be fetched per outer join. Hibernate forbids
-                Cartesian products when possible, <literal>SELECT</literal>ing two collections per
-                outer join would create one. This would almost always be slower than two (lazy or
-                non-deferred) <literal>SELECT</literal>s. The restriction to a single outer-joined
-                collection applies to both the mapping fetching strategies and to HQL/Criteria 
-                queries.
-            </para>
-            
-            <para>
-                If you run into this limitation, you should use subselect or batch fetching to
-                achieve acceptable performance. This is common when retrieving a tree of
-                collection-valued associations.
-            </para>
-            
-            <para>
-                There are no restrictions to join fetching of single-ended associations.
-            </para>
 
             <para>
                 A completely different way to avoid problems with N+1 selects is to use the 
diff --git a/reference/en/modules/query_hql.xml b/reference/en/modules/query_hql.xml
index 0cc8c075ef..61495a5748 100644
--- a/reference/en/modules/query_hql.xml
+++ b/reference/en/modules/query_hql.xml
@@ -148,9 +148,7 @@
         </para>
         
         <para>
-            Note that, in the current implementation, only one collection role may be join fetched
-            in a query (more than one role will usually result in a cartesian product). Note also 
-            that the <literal>fetch</literal> construct may not be used in queries called using
+            Note that the <literal>fetch</literal> construct may not be used in queries called using
             <literal>scroll()</literal> or <literal>iterate()</literal>. Finally, note that
             <literal>full join fetch</literal> and <literal>right join fetch</literal> are not 
             meaningful.