diff options
Diffstat (limited to 'doc/src')
| -rw-r--r-- | doc/src/sgml/protocol.sgml | 28 |
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> |