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