Change processing of extended-Query mode so that an unnamed statement

that has parameters is always planned afresh for each Bind command,
treating the parameter values as constants in the planner.  This removes
the performance penalty formerly often paid for using out-of-line
parameters --- with this definition, the planner can do constant folding,
LIKE optimization, etc.  After a suggestion by Andrew@supernews.

1 files changed, 10 insertions, 18 deletions

diff --git a/doc/src/sgml/protocol.sgml b/doc/src/sgml/protocol.sgml
index 009cedd8683..ef2ece938f6 100644
--- a/doc/src/sgml/protocol.sgml
+++ b/doc/src/sgml/protocol.sgml
@@ -1,4 +1,4 @@
-<!-- $PostgreSQL: pgsql/doc/src/sgml/protocol.sgml,v 1.65 2006/06/18 15:38:36 petere Exp $ -->
+<!-- $PostgreSQL: pgsql/doc/src/sgml/protocol.sgml,v 1.66 2006/09/06 20:40:47 tgl Exp $ -->
 
 <chapter id="protocol">
  <title>Frontend/Backend Protocol</title>
@@ -126,8 +126,9 @@
     into multiple steps.  The state retained between steps is represented
     by two types of objects: <firstterm>prepared statements</> and
     <firstterm>portals</>.  A prepared statement represents the result of
-    parsing, semantic analysis, and planning of a textual query string.  A
-    prepared statement is not necessarily ready to execute, because it may
+    parsing, semantic analysis, and (optionally) planning of a textual query
+    string.
+    A prepared statement is not necessarily ready to execute, because it may
     lack specific values for <firstterm>parameters</>.  A portal represents
     a ready-to-execute or already-partially-executed statement, with any
     missing parameter values filled in.  (For <command>SELECT</> statements,
@@ -693,7 +694,7 @@
 
    <para>
     Query planning for named prepared-statement objects occurs when the Parse
-    message is received. If a query will be repeatedly executed with
+    message is processed. If a query will be repeatedly executed with
     different parameters, it may be beneficial to send a single Parse message
     containing a parameterized query, followed by multiple Bind
     and Execute messages. This will avoid replanning the query on each
@@ -703,9 +704,9 @@
    <para>
     The unnamed prepared statement is likewise planned during Parse processing
     if the Parse message defines no parameters.  But if there are parameters,
-    query planning is delayed until the first Bind message for the statement
-    is received. The planner will consider the actual values of the parameters
-    provided in the Bind message when planning the query.
+    query planning occurs during Bind processing instead.  This allows the
+    planner to make use of the actual values of the parameters provided in
+    the Bind message when planning the query.
    </para>
 
    <note>
@@ -717,17 +718,8 @@
      planning a parameterized query assigned to a named prepared-statement
      object.  This possible penalty is avoided when using the unnamed
      statement, since it is not planned until actual parameter values are
-     available.
-    </para>
-
-    <para>
-     If a second or subsequent Bind referencing the unnamed prepared-statement
-     object is received without an intervening Parse, the query is
-     not replanned. The parameter values used in the first Bind message may
-     produce a query plan that is only efficient for a subset of possible
-     parameter values. To force replanning of the query for a fresh set of
-     parameters, send another Parse message to replace the unnamed
-     prepared-statement object. 
+     available.  The cost is that planning must occur afresh for each Bind,
+     even if the query stays the same.
     </para>
    </note>