More minor updates and copy-editing.

doc/src/sgml/indices.sgml

-<!-- $PostgreSQL: pgsql/doc/src/sgml/indices.sgml,v 1.47 2003/11/29 19:51:37 pgsql Exp $ -->
+<!-- $PostgreSQL: pgsql/doc/src/sgml/indices.sgml,v 1.48 2004/12/23 23:07:38 tgl Exp $ -->
 
 <chapter id="indexes">
  <title id="indexes-title">Indexes</title>
@@ -71,7 +71,7 @@ CREATE INDEX test1_id_index ON test1 (id);
   </para>
 
   <para>
-   Once the index is created, no further intervention is required: the
+   Once an index is created, no further intervention is required: the
    system will update the index when the table is modified, and it will
    use the index in queries when it thinks this would be more efficient
    than a sequential table scan.  But you may have to run the
@@ -761,7 +761,7 @@ CREATE UNIQUE INDEX tests_success_constraint ON tests (subject, target)
     </para>
 
     <para>
-     It is especially fatal to use proportionally reduced data sets.
+     It is especially fatal to use very small test data sets.
      While selecting 1000 out of 100000 rows could be a candidate for
      an index, selecting 1 out of 100 rows will hardly be, because the
      100 rows will probably fit within a single disk page, and there

doc/src/sgml/mvcc.sgml

 <!--
-$PostgreSQL: pgsql/doc/src/sgml/mvcc.sgml,v 2.45 2004/11/15 06:32:14 neilc Exp $
+$PostgreSQL: pgsql/doc/src/sgml/mvcc.sgml,v 2.46 2004/12/23 23:07:38 tgl Exp $
 -->
 
  <chapter id="mvcc">
@@ -206,9 +206,9 @@ $PostgreSQL: pgsql/doc/src/sgml/mvcc.sgml,v 2.45 2004/11/15 06:32:14 neilc Exp $
     </table>
 
    <para>
-    In <productname>PostgreSQL</productname>, you can use all four
-    possible transaction isolation levels.  Internally, there are only
-    two distinct isolation levels, which correspond to the levels Read
+    In <productname>PostgreSQL</productname>, you can request any of the
+    four standard transaction isolation levels.  But internally, there are
+    only two distinct isolation levels, which correspond to the levels Read
     Committed and Serializable.  When you select the level Read
     Uncommitted you really get Read Committed, and when you select
     Repeatable Read you really get Serializable, so the actual
@@ -217,7 +217,7 @@ $PostgreSQL: pgsql/doc/src/sgml/mvcc.sgml,v 2.45 2004/11/15 06:32:14 neilc Exp $
     define which phenomena must not happen, they do not define which
     phenomena must happen.  The reason that <productname>PostgreSQL</>
     only provides two isolation levels is that this is the only
-    sensible way to map the isolation levels to the multiversion
+    sensible way to map the standard isolation levels to the multiversion
     concurrency control architecture.  The behavior of the available
     isolation levels is detailed in the following subsections.
    </para>

doc/src/sgml/perform.sgml

 <!--
-$PostgreSQL: pgsql/doc/src/sgml/perform.sgml,v 1.48 2004/12/01 19:00:27 tgl Exp $
+$PostgreSQL: pgsql/doc/src/sgml/perform.sgml,v 1.49 2004/12/23 23:07:38 tgl Exp $
 -->
 
  <chapter id="performance-tips">
@@ -78,7 +78,7 @@ $PostgreSQL: pgsql/doc/src/sgml/perform.sgml,v 1.48 2004/12/01 19:00:27 tgl Exp
     estimates are converted into disk-page units using some
     fairly arbitrary fudge factors. If you want to experiment with these
     factors, see the list of run-time configuration parameters in
-    <xref linkend="runtime-config-resource">.)
+    <xref linkend="runtime-config-query-constants">.)
    </para>
 
    <para>
@@ -657,16 +657,6 @@ SELECT * FROM x, y, a, b, c WHERE something AND somethingelse;
     point would be rolled back, so you won't be stuck with partially
     loaded data.
    </para>
-
-   <para>
-    If you are issuing a large sequence of <command>INSERT</command>
-    commands to bulk load some data, also consider using <xref
-    linkend="sql-prepare" endterm="sql-prepare-title"> to create a
-    prepared <command>INSERT</command> statement. Since you are
-    executing the same command multiple times, it is more efficient to
-    prepare the command once and then use <command>EXECUTE</command>
-    as many times as required.
-   </para>
   </sect2>
 
   <sect2 id="populate-copy-from">
@@ -683,12 +673,20 @@ SELECT * FROM x, y, a, b, c WHERE something AND somethingelse;
     use this method to populate a table.
    </para>
 
+   <para>
+    If you cannot use <command>COPY</command>, it may help to use <xref
+    linkend="sql-prepare" endterm="sql-prepare-title"> to create a
+    prepared <command>INSERT</command> statement, and then use
+    <command>EXECUTE</command> as many times as required.  This avoids
+    some of the overhead of repeatedly parsing and planning
+    <command>INSERT</command>.
+   </para>
+
    <para>
     Note that loading a large number of rows using
     <command>COPY</command> is almost always faster than using
-    <command>INSERT</command>, even if multiple
-    <command>INSERT</command> commands are batched into a single
-    transaction.
+    <command>INSERT</command>, even if <command>PREPARE</> is used and
+    multiple insertions are batched into a single transaction.
    </para>
   </sect2>
 
@@ -719,10 +717,10 @@ SELECT * FROM x, y, a, b, c WHERE something AND somethingelse;
 
    <para>
     Temporarily increasing the <xref linkend="guc-maintenance-work-mem">
-    configuration variable when restoring large amounts of data can
+    configuration variable when loading large amounts of data can
     lead to improved performance. This is because when a B-tree index
     is created from scratch, the existing content of the table needs
-    to be sorted. Allowing the external merge sort to use more memory
+    to be sorted. Allowing the merge sort to use more memory
     means that fewer merge passes will be required.  A larger setting for
     <varname>maintenance_work_mem</varname> may also speed up validation
     of foreign-key constraints.
@@ -754,8 +752,7 @@ SELECT * FROM x, y, a, b, c WHERE something AND somethingelse;
     Whenever you have significantly altered the distribution of data
     within a table, running <xref linkend="sql-analyze"
     endterm="sql-analyze-title"> is strongly recommended. This
-    includes when bulk loading large amounts of data into
-    <productname>PostgreSQL</productname>.  Running
+    includes bulk loading large amounts of data into the table.  Running
     <command>ANALYZE</command> (or <command>VACUUM ANALYZE</command>)
     ensures that the planner has up-to-date statistics about the
     table.  With no statistics or obsolete statistics, the planner may

doc/src/sgml/typeconv.sgml

 <!--
-$PostgreSQL: pgsql/doc/src/sgml/typeconv.sgml,v 1.42 2003/12/14 00:10:32 neilc Exp $
+$PostgreSQL: pgsql/doc/src/sgml/typeconv.sgml,v 1.43 2004/12/23 23:07:38 tgl Exp $
 -->
 
 <chapter Id="typeconv">
@@ -22,8 +22,7 @@ In many cases a user will not need
 to understand the details of the type conversion mechanism.
 However, the implicit conversions done by <productname>PostgreSQL</productname>
 can affect the results of a query.  When necessary, these results
-can be tailored by a user or programmer
-using <emphasis>explicit</emphasis> type conversion.
+can be tailored by using <emphasis>explicit</emphasis> type conversion.
 </para>
 
 <para>
@@ -43,16 +42,17 @@ has an associated data type which determines its behavior and allowed usage.
 <productname>PostgreSQL</productname> has an extensible type system that is
 much more general and flexible than other <acronym>SQL</acronym> implementations.
 Hence, most type conversion behavior in <productname>PostgreSQL</productname>
-should be governed by general rules rather than by <foreignphrase>ad hoc</> heuristics, to allow
+is governed by general rules rather than by <foreignphrase>ad hoc</>
+heuristics.  This allows
 mixed-type expressions to be meaningful even with user-defined types.
 </para>
 
 <para>
-The <productname>PostgreSQL</productname> scanner/parser decodes lexical
-elements into only five fundamental categories: integers, floating-point numbers, strings,
-names, and key words.  Constants of most non-numeric types are first classified as
-strings. The <acronym>SQL</acronym> language definition allows specifying type
-names with strings, and this mechanism can be used in
+The <productname>PostgreSQL</productname> scanner/parser divides lexical
+elements into only five fundamental categories: integers, non-integer numbers,
+strings, identifiers, and key words.  Constants of most non-numeric types are
+first classified as strings. The <acronym>SQL</acronym> language definition
+allows specifying type names with strings, and this mechanism can be used in
 <productname>PostgreSQL</productname> to start the parser down the correct
 path. For example, the query
 
@@ -79,28 +79,30 @@ parser:
 <variablelist>
 <varlistentry>
 <term>
-Operators
+Function calls
 </term>
 <listitem>
 <para>
-<productname>PostgreSQL</productname> allows expressions with
-prefix and postfix unary (one-argument) operators,
-as well as binary (two-argument) operators.
+Much of the <productname>PostgreSQL</productname> type system is built around a
+rich set of functions. Functions can have one or more arguments.
+Since <productname>PostgreSQL</productname> permits function
+overloading, the function name alone does not uniquely identify the function
+to be called; the parser must select the right function based on the data
+types of the supplied arguments.
 </para>
 </listitem>
 </varlistentry>
 <varlistentry>
 <term>
-Function calls
+Operators
 </term>
 <listitem>
 <para>
-Much of the <productname>PostgreSQL</productname> type system is built around a
-rich set of functions. Function calls can have one or more arguments.
-Since <productname>PostgreSQL</productname> permits function
-overloading, the function name alone does not uniquely identify the function
-to be called; the parser must select the right function based on the data
-types of the supplied arguments.
+<productname>PostgreSQL</productname> allows expressions with
+prefix and postfix unary (one-argument) operators,
+as well as binary (two-argument) operators.  Like functions, operators can
+be overloaded, and so the same problem of selecting the right operator
+exists.
 </para>
 </listitem>
 </varlistentry>
@@ -125,7 +127,7 @@ with, and perhaps converted to, the types of the target columns.
 Since all query results from a unionized <command>SELECT</command> statement
 must appear in a single set of columns, the types of the results of each
 <command>SELECT</> clause must be matched up and converted to a uniform set.
-Similarly, the branch expressions of a <literal>CASE</> construct must be
+Similarly, the result expressions of a <literal>CASE</> construct must be
 converted to a common type so that the <literal>CASE</> expression as a whole
 has a known output type.  The same holds for <literal>ARRAY</> constructs.
 </para>
@@ -728,12 +730,16 @@ type.
 
 <step performance="required">
 <para>
-If the target is a fixed-length type (e.g., <type>char</type> or <type>varchar</type>
-declared with a length) then try to find a sizing function for the target
-type.  A sizing function is a function of the same name as the type,
-taking two arguments of which the first is that type and the second is of type
-<type>integer</type>, and returning the same type.  If one is found, it is applied,
-passing the column's declared length as the second parameter.
+Check to see if there is a sizing cast for the target type.  A sizing
+cast is a cast from that type to itself.  If one is found in the
+<structname>pg_cast</> catalog, apply it to the expression before storing
+into the destination column.  The implementation function for such a cast
+always takes an extra parameter of type <type>integer</type>, which receives
+the destination column's declared length (actually, its
+<structfield>atttypmod</> value; the interpretation of
+<structfield>atttypmod</> varies for different datatypes).  The cast function
+is responsible for applying any length-dependent semantics such as size
+checking or truncation.
 </para>
 </step>