aboutsummaryrefslogtreecommitdiff
path: root/doc/src
diff options
context:
space:
mode:
authorTom Lane <tgl@sss.pgh.pa.us>2019-02-09 18:32:23 -0500
committerTom Lane <tgl@sss.pgh.pa.us>2019-02-09 18:32:23 -0500
commita391ff3c3d418e404a2c6e4ff0865a107752827b (patch)
treef076c5785d06e7ccf082b08c1651b17d95af4563 /doc/src
parent1fb57af92069ee104c09e2016af9e0e620681be3 (diff)
downloadpostgresql-a391ff3c3d418e404a2c6e4ff0865a107752827b.tar.gz
postgresql-a391ff3c3d418e404a2c6e4ff0865a107752827b.zip
Build out the planner support function infrastructure.
Add support function requests for estimating the selectivity, cost, and number of result rows (if a SRF) of the target function. The lack of a way to estimate selectivity of a boolean-returning function in WHERE has been a recognized deficiency of the planner since Berkeley days. This commit finally fixes it. In addition, non-constant estimates of cost and number of output rows are now possible. We still fall back to looking at procost and prorows if the support function doesn't service the request, of course. To make concrete use of the possibility of estimating output rowcount for SRFs, this commit adds support functions for array_unnest(anyarray) and the integer variants of generate_series; the lack of plausible rowcount estimates for those, even when it's obvious to a human, has been a repeated subject of complaints. Obviously, much more could now be done in this line, but I'm mostly just trying to get the infrastructure in place. Discussion: https://postgr.es/m/15193.1548028093@sss.pgh.pa.us
Diffstat (limited to 'doc/src')
-rw-r--r--doc/src/sgml/xfunc.sgml21
1 files changed, 21 insertions, 0 deletions
diff --git a/doc/src/sgml/xfunc.sgml b/doc/src/sgml/xfunc.sgml
index d70aa6eed78..b486ef391ee 100644
--- a/doc/src/sgml/xfunc.sgml
+++ b/doc/src/sgml/xfunc.sgml
@@ -3439,4 +3439,25 @@ supportfn(internal) returns internal
simplify. Ensure rigorous equivalence between the simplified
expression and an actual execution of the target function.
</para>
+
+ <para>
+ For target functions that return boolean, it is often useful to estimate
+ the fraction of rows that will be selected by a WHERE clause using that
+ function. This can be done by a support function that implements
+ the <literal>SupportRequestSelectivity</literal> request type.
+ </para>
+
+ <para>
+ If the target function's runtime is highly dependent on its inputs,
+ it may be useful to provide a non-constant cost estimate for it.
+ This can be done by a support function that implements
+ the <literal>SupportRequestCost</literal> request type.
+ </para>
+
+ <para>
+ For target functions that return sets, it is often useful to provide
+ a non-constant estimate for the number of rows that will be returned.
+ This can be done by a support function that implements
+ the <literal>SupportRequestRows</literal> request type.
+ </para>
</sect1>