diff --git a/doc/rbac-performance-analysis.md b/doc/rbac-performance-analysis.md
index fcd9781a..621d1248 100644
--- a/doc/rbac-performance-analysis.md
+++ b/doc/rbac-performance-analysis.md
@@ -417,6 +417,14 @@ Implementing this approach would be a bit difficult anyway, because we would nee
 
 See the related queries in [recursive-cte-experiments-for-accessible-uuids.sql](../sql/recursive-cte-experiments-for-accessible-uuids.sql). They might have changed independently since this document was written, but you can still check out the old version from git.
 
+### Rearranging the Parts of the CTE-Query
+
+I also moved the function call which determines into its own WITH-section, with no improvement.
+
+Experimentally I moved the business condition into the CTE SELECT, also with no improvement.
+
+Such rearrangements seem to be sucessfully done by the PostgreSQL query optimizer.
+
 ## Summary
 
 ### What we did Achieve?
@@ -425,13 +433,19 @@ In a first step, the total import runtime for office entities was reduced from a
 
 In a second step, we reduced the import of booking- and hosting-assets from about 100min (not counting the required office entities) to 5min.
 
-### What Helped?
+### What did not Help?
+
+Rearranging the CTE query by extracting parts into WITH-clauses did not improve the performance.
+
+Surprisingly little performance gain (<10% improvement) came from reducing the result of the CTE query by moving the hosting asset type into RBAC-system and using it in the inner SELECT query instead of in the outer SELECT query of the application side. 
+
+### What did Help?
 
 Merging the recursive CTE query to determine the RBAC SELECT-permission, made it more clear which business-queries take the time.
 
 Avoiding EAGER-loading where not necessary, reduced the total runtime of the import to about the half.
 
-The major improvement came from using direct INSERT statements, which then also bypassed the RBAC SELECT permission checks.
+The major improvement came from using direct INSERT statements, which avoided some SELECT statements unnecessarily generated by the EntityManager and also completely bypassed the RBAC SELECT permission checks.
 
 ### What Still Has To Be Done?
 
diff --git a/sql/recursive-cte-experiments-for-accessible-uuids.sql b/sql/recursive-cte-experiments-for-accessible-uuids.sql
index 7fa5ab32..081aab5d 100644
--- a/sql/recursive-cte-experiments-for-accessible-uuids.sql
+++ b/sql/recursive-cte-experiments-for-accessible-uuids.sql
@@ -17,7 +17,7 @@ create view hs_hosting_asset_example_rv as
                                 true
                     from rbacgrants
                     where (rbacgrants.ascendantuuid = any (currentsubjectsuuids()))
-                --and rbacgrants.assumed
+                      and rbacgrants.assumed
                 union all
                 select distinct g.descendantuuid,
                                 g.ascendantuuid,