On Fri, Jun 3, 2016 at 08:27:38AM -0400, David G. Johnston wrote:
> This goes back to Bruce's motivation but as long as it goes into the
> internals
> section I have no problem adding material that someone felt was worth their
OK, updated version attached. I added "potential" to the first
paragraph, and added "estimated cost" to the later part, fixed the
"cheaper than", and clarified that we add the plan time cost to the
non-generic plan, which is how it can be cheaper than the generic plan.
I also moved the "Once a generic plan is chosen" line.
Yeah, that's a lot of changes, but they all improved the text. Thanks.
--
Bruce Momjian <br...@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +
diff --git a/doc/src/sgml/ref/prepare.sgml b/doc/src/sgml/ref/prepare.sgml
new file mode 100644
index dbce8f2..af6c15e
*** a/doc/src/sgml/ref/prepare.sgml
--- b/doc/src/sgml/ref/prepare.sgml
*************** PREPARE <replaceable class="PARAMETER">n
*** 70,80 ****
</para>
<para>
! Prepared statements have the largest performance advantage when a
! single session is being used to execute a large number of similar
statements. The performance difference will be particularly
! significant if the statements are complex to plan or rewrite, for
! example, if the query involves a join of many tables or requires
the application of several rules. If the statement is relatively simple
to plan and rewrite but relatively expensive to execute, the
performance advantage of prepared statements will be less noticeable.
--- 70,80 ----
</para>
<para>
! Prepared statements potentially have the largest performance advantage
! when a single session is being used to execute a large number of similar
statements. The performance difference will be particularly
! significant if the statements are complex to plan or rewrite, e.g.
! if the query involves a join of many tables or requires
the application of several rules. If the statement is relatively simple
to plan and rewrite but relatively expensive to execute, the
performance advantage of prepared statements will be less noticeable.
*************** PREPARE <replaceable class="PARAMETER">n
*** 127,140 ****
<title>Notes</title>
<para>
! If a prepared statement is executed enough times, the server may eventually
! decide to save and re-use a generic plan rather than re-planning each time.
! This will occur immediately if the prepared statement has no parameters;
! otherwise it occurs only if the generic plan appears to be not much more
! expensive than a plan that depends on specific parameter values.
! Typically, a generic plan will be selected only if the query's performance
! is estimated to be fairly insensitive to the specific parameter values
! supplied.
</para>
<para>
--- 127,151 ----
<title>Notes</title>
<para>
! Prepared statements can optionally use generic plans rather than
! re-planning with each set of supplied <command>EXECUTE</command> values.
! This occurs immediately for prepared statements with no parameters;
! otherwise it occurs only after five or more executions produce estimated
! plan costs, with planning overhead added, that are, on average, more
! expensive than the generic plan cost. Once a generic plan is chosen,
! it is used for the remaining lifetime of the prepared statement.
! </para>
!
! <para>
! A generic plan assumes each value supplied to <command>EXECUTE</command>
! is one of the column's distinct values and that column values are
! uniformly distributed. For example, if statistics records three
! distinct column values, a generic plan assumes a column equality
! comparison will match 33% of processed rows. Column statistics
! also allows generic plans to accurately compute the selectivity of
! unique columns. Comparisons on non-uniformly-distributed columns and
! specification of non-existent values affects the average plan cost,
! and hence if and when a generic plan is chosen.
</para>
<para>
*************** PREPARE <replaceable class="PARAMETER">n
*** 142,148 ****
for a prepared statement, use <xref linkend="sql-explain">.
If a generic plan is in use, it will contain parameter symbols
<literal>$<replaceable>n</></literal>, while a custom plan will have the
! current actual parameter values substituted into it.
</para>
<para>
--- 153,161 ----
for a prepared statement, use <xref linkend="sql-explain">.
If a generic plan is in use, it will contain parameter symbols
<literal>$<replaceable>n</></literal>, while a custom plan will have the
! supplied parameter values substituted into it.
! The row estimates in the generic plan reflect the selectivity
! computed for the parameters.
</para>
<para>
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
