aboutsummaryrefslogtreecommitdiff
path: root/doc/src
diff options
context:
space:
mode:
Diffstat (limited to 'doc/src')
-rw-r--r--doc/src/sgml/protocol.sgml28
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>