From a276392e5223a9cdb3160ecde8e4baa43e45cd66 Mon Sep 17 00:00:00 2001
From: Tom Lane <tgl@sss.pgh.pa.us>
Date: Mon, 19 Feb 2001 00:24:30 +0000
Subject: [PATCH] Update example of partially constraining join order to use a
 subselect in FROM instead of an auxiliary view.  We didn't have
 subselect-in-FROM when I wrote this originally...

---
 doc/src/sgml/perform.sgml | 11 ++++++-----
 1 file changed, 6 insertions(+), 5 deletions(-)

diff --git a/doc/src/sgml/perform.sgml b/doc/src/sgml/perform.sgml
index 897073742b..35ed28875f 100644
--- a/doc/src/sgml/perform.sgml
+++ b/doc/src/sgml/perform.sgml
@@ -1,5 +1,5 @@
 <!--
-$Header: /cvsroot/pgsql/doc/src/sgml/perform.sgml,v 1.1 2000/12/16 02:29:36 tgl Exp $
+$Header: /cvsroot/pgsql/doc/src/sgml/perform.sgml,v 1.2 2001/02/19 00:24:30 tgl Exp $
 -->
 
  <chapter id="performance-tips">
@@ -350,10 +350,11 @@ SELECT * FROM a CROSS JOIN b, c, d, e WHERE ...;
    might not want to constrain the planner's search for a good ordering
    of inner joins inside an outer join.  You can't do that directly in the
    JOIN syntax, but you can get around the syntactic limitation by using
-   views.  For example,
+   subselects.  For example,
     <programlisting>
-CREATE VIEW v1 AS SELECT ... FROM a, b, c WHERE ...;
-SELECT * FROM d LEFT JOIN v1 ON (...);
+SELECT * FROM d LEFT JOIN
+        (SELECT * FROM a, b, c WHERE ...) AS ss
+        ON (...);
     </programlisting>
    Here, joining D must be the last step in the query plan, but the
    planner is free to consider various join orders for A,B,C.
@@ -397,7 +398,7 @@ SELECT * FROM d LEFT JOIN v1 ON (...);
     command, instead
     of a series of INSERT commands.  This reduces parsing, planning, etc
     overhead a great deal. If you do this then it's not necessary to fool
-    around with autocommit.
+    around with autocommit, since it's only one command anyway.
    </para>
   </sect2>