database/postgres
1
0
Fork 0
mirror of https://github.com/postgres/postgres.git synced 2025-07-27 12:41:57 +03:00
Code Activity

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

Browse Source 
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.
This commit is contained in:
Tom Lane
2006-09-06 20:40:48 +00:00
parent 389870b256
commit 5983a1aaa9
10 changed files with 122 additions and 66 deletions
Download Patch File Download Diff File Expand all files Collapse all files

28
doc/src/sgml/protocol.sgml
View File

@ -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>