Home Explore Blog CI



postgresql

52th chunk of `doc/src/sgml/xfunc.sgml`
c9044b369a7de34418cb8414aff10975006cb9e03736c4360000000100000b01
 <quote>black box</quote> that the
    database system knows very little about the behavior of.  However,
    that means that queries using the function may be executed much less
    efficiently than they could be.  It is possible to supply additional
    knowledge that helps the planner optimize function calls.
   </para>

   <para>
    Some basic facts can be supplied by declarative annotations provided in
    the <link linkend="sql-createfunction"><command>CREATE FUNCTION</command></link> command.  Most important of
    these is the function's <link linkend="xfunc-volatility">volatility
    category</link> (<literal>IMMUTABLE</literal>, <literal>STABLE</literal>,
    or <literal>VOLATILE</literal>); one should always be careful to
    specify this correctly when defining a function.
    The parallel safety property (<literal>PARALLEL
    UNSAFE</literal>, <literal>PARALLEL RESTRICTED</literal>, or
    <literal>PARALLEL SAFE</literal>) must also be specified if you hope
    to use the function in parallelized queries.
    It can also be useful to specify the function's estimated execution
    cost, and/or the number of rows a set-returning function is estimated
    to return.  However, the declarative way of specifying those two
    facts only allows specifying a constant value, which is often
    inadequate.
   </para>

   <para>
    It is also possible to attach a <firstterm>planner support
    function</firstterm> to an SQL-callable function (called
    its <firstterm>target function</firstterm>), and thereby provide
    knowledge about the target function that is too complex to be
    represented declaratively.  Planner support functions have to be
    written in C (although their target functions might not be), so this is
    an advanced feature that relatively few people will use.
   </para>

   <para>
    A planner support function must have the SQL signature
<programlisting>
supportfn(internal) returns internal
</programlisting>
    It is attached to its target function by specifying
    the <literal>SUPPORT</literal> clause when creating the target function.
   </para>

   <para>
    The details of the API for planner support functions can be found in
    file <filename>src/include/nodes/supportnodes.h</filename> in the
    <productname>PostgreSQL</productname> source code.  Here we provide
    just an overview of what planner support functions can do.
    The set of possible requests to a support function is extensible,
    so more things might be possible in future versions.
   </para>

   <para>
    Some function calls can be simplified during planning based on
    properties specific to the function.  For example,
    <literal>int4mul(n, 1)</literal> could be simplified to
    just <literal>n</literal>.  This type of transformation can be
    performed

Title: Function Optimization in PostgreSQL: Declarative Annotations and Planner Support Functions
Summary
This section details how to optimize function calls in PostgreSQL by providing additional information to the query planner. Basic facts can be supplied through declarative annotations in CREATE FUNCTION, such as volatility and parallel safety. For more complex scenarios, a planner support function, written in C, can be attached to an SQL-callable function to provide knowledge that's too intricate for declarative representation. The API details for planner support functions are found in src/include/nodes/supportnodes.h. These functions can simplify function calls during planning based on function-specific properties.