Sophie

Sophie

distrib > Mageia > 7 > armv7hl > media > core-updates > by-pkgid > 5fea23694c765462b86d6ddf74461eab > files > 154

postgresql9.6-docs-9.6.22-1.mga7.noarch.rpm

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<HTML
><HEAD
><TITLE
>Creating Custom Scan Paths</TITLE
><META
NAME="GENERATOR"
CONTENT="Modular DocBook HTML Stylesheet Version 1.79"><LINK
REV="MADE"
HREF="mailto:pgsql-docs@postgresql.org"><LINK
REL="HOME"
TITLE="PostgreSQL 9.6.22 Documentation"
HREF="index.html"><LINK
REL="UP"
TITLE="Writing A Custom Scan Provider"
HREF="custom-scan.html"><LINK
REL="PREVIOUS"
TITLE="Writing A Custom Scan Provider"
HREF="custom-scan.html"><LINK
REL="NEXT"
TITLE="Creating Custom Scan Plans"
HREF="custom-scan-plan.html"><LINK
REL="STYLESHEET"
TYPE="text/css"
HREF="stylesheet.css"><META
HTTP-EQUIV="Content-Type"
CONTENT="text/html; charset=ISO-8859-1"><META
NAME="creation"
CONTENT="2021-05-18T09:16:10"></HEAD
><BODY
CLASS="SECT1"
><DIV
CLASS="NAVHEADER"
><TABLE
SUMMARY="Header navigation table"
WIDTH="100%"
BORDER="0"
CELLPADDING="0"
CELLSPACING="0"
><TR
><TH
COLSPAN="4"
ALIGN="center"
VALIGN="bottom"
><A
HREF="index.html"
>PostgreSQL 9.6.22 Documentation</A
></TH
></TR
><TR
><TD
WIDTH="10%"
ALIGN="left"
VALIGN="top"
><A
TITLE="Writing A Custom Scan Provider"
HREF="custom-scan.html"
ACCESSKEY="P"
>Prev</A
></TD
><TD
WIDTH="10%"
ALIGN="left"
VALIGN="top"
><A
HREF="custom-scan.html"
ACCESSKEY="U"
>Up</A
></TD
><TD
WIDTH="60%"
ALIGN="center"
VALIGN="bottom"
>Chapter 57. Writing A Custom Scan Provider</TD
><TD
WIDTH="20%"
ALIGN="right"
VALIGN="top"
><A
TITLE="Creating Custom Scan Plans"
HREF="custom-scan-plan.html"
ACCESSKEY="N"
>Next</A
></TD
></TR
></TABLE
><HR
ALIGN="LEFT"
WIDTH="100%"></DIV
><DIV
CLASS="SECT1"
><H1
CLASS="SECT1"
><A
NAME="CUSTOM-SCAN-PATH"
>57.1. Creating Custom Scan Paths</A
></H1
><P
>    A custom scan provider will typically add paths for a base relation by
    setting the following hook, which is called after the core code has
    generated all the access paths it can for the relation (except for
    Gather paths, which are made after this call so that they can use
    partial paths added by the hook):
</P><PRE
CLASS="PROGRAMLISTING"
>typedef void (*set_rel_pathlist_hook_type) (PlannerInfo *root,
                                            RelOptInfo *rel,
                                            Index rti,
                                            RangeTblEntry *rte);
extern PGDLLIMPORT set_rel_pathlist_hook_type set_rel_pathlist_hook;</PRE
><P>
  </P
><P
>    Although this hook function can be used to examine, modify, or remove
    paths generated by the core system, a custom scan provider will typically
    confine itself to generating <TT
CLASS="STRUCTNAME"
>CustomPath</TT
> objects and adding
    them to <TT
CLASS="LITERAL"
>rel</TT
> using <CODE
CLASS="FUNCTION"
>add_path</CODE
>.  The custom scan
    provider is responsible for initializing the <TT
CLASS="STRUCTNAME"
>CustomPath</TT
>
    object, which is declared like this:
</P><PRE
CLASS="PROGRAMLISTING"
>typedef struct CustomPath
{
    Path      path;
    uint32    flags;
    List     *custom_paths;
    List     *custom_private;
    const CustomPathMethods *methods;
} CustomPath;</PRE
><P>
  </P
><P
>    <TT
CLASS="STRUCTFIELD"
>path</TT
> must be initialized as for any other path, including
    the row-count estimate, start and total cost, and sort ordering provided
    by this path.  <TT
CLASS="STRUCTFIELD"
>flags</TT
> is a bit mask, which should include
    <TT
CLASS="LITERAL"
>CUSTOMPATH_SUPPORT_BACKWARD_SCAN</TT
> if the custom path can support
    a backward scan and <TT
CLASS="LITERAL"
>CUSTOMPATH_SUPPORT_MARK_RESTORE</TT
> if it
    can support mark and restore.  Both capabilities are optional.
    An optional <TT
CLASS="STRUCTFIELD"
>custom_paths</TT
> is a list of <TT
CLASS="STRUCTNAME"
>Path</TT
>
    nodes used by this custom-path node; these will be transformed into
    <TT
CLASS="STRUCTNAME"
>Plan</TT
> nodes by planner.
    <TT
CLASS="STRUCTFIELD"
>custom_private</TT
> can be used to store the custom path's
    private data.  Private data should be stored in a form that can be handled
    by <TT
CLASS="LITERAL"
>nodeToString</TT
>, so that debugging routines that attempt to
    print the custom path will work as designed.  <TT
CLASS="STRUCTFIELD"
>methods</TT
> must
    point to a (usually statically allocated) object implementing the required
    custom path methods, of which there is currently only one.
  </P
><P
>   A custom scan provider can also provide join paths.  Just as for base
   relations, such a path must produce the same output as would normally be
   produced by the join it replaces.  To do this, the join provider should
   set the following hook, and then within the hook function,
   create <TT
CLASS="STRUCTNAME"
>CustomPath</TT
> path(s) for the join relation.
</P><PRE
CLASS="PROGRAMLISTING"
>typedef void (*set_join_pathlist_hook_type) (PlannerInfo *root,
                                             RelOptInfo *joinrel,
                                             RelOptInfo *outerrel,
                                             RelOptInfo *innerrel,
                                             JoinType jointype,
                                             JoinPathExtraData *extra);
extern PGDLLIMPORT set_join_pathlist_hook_type set_join_pathlist_hook;</PRE
><P>

   This hook will be invoked repeatedly for the same join relation, with
   different combinations of inner and outer relations; it is the
   responsibility of the hook to minimize duplicated work.
  </P
><DIV
CLASS="SECT2"
><H2
CLASS="SECT2"
><A
NAME="CUSTOM-SCAN-PATH-CALLBACKS"
>57.1.1. Custom Scan Path Callbacks</A
></H2
><P
></P><PRE
CLASS="PROGRAMLISTING"
>Plan *(*PlanCustomPath) (PlannerInfo *root,
                         RelOptInfo *rel,
                         CustomPath *best_path,
                         List *tlist,
                         List *clauses,
                         List *custom_plans);</PRE
><P>
    Convert a custom path to a finished plan.  The return value will generally
    be a <TT
CLASS="LITERAL"
>CustomScan</TT
> object, which the callback must allocate and
    initialize.  See <A
HREF="custom-scan-plan.html"
>Section 57.2</A
> for more details.
   </P
></DIV
></DIV
><DIV
CLASS="NAVFOOTER"
><HR
ALIGN="LEFT"
WIDTH="100%"><TABLE
SUMMARY="Footer navigation table"
WIDTH="100%"
BORDER="0"
CELLPADDING="0"
CELLSPACING="0"
><TR
><TD
WIDTH="33%"
ALIGN="left"
VALIGN="top"
><A
HREF="custom-scan.html"
ACCESSKEY="P"
>Prev</A
></TD
><TD
WIDTH="34%"
ALIGN="center"
VALIGN="top"
><A
HREF="index.html"
ACCESSKEY="H"
>Home</A
></TD
><TD
WIDTH="33%"
ALIGN="right"
VALIGN="top"
><A
HREF="custom-scan-plan.html"
ACCESSKEY="N"
>Next</A
></TD
></TR
><TR
><TD
WIDTH="33%"
ALIGN="left"
VALIGN="top"
>Writing A Custom Scan Provider</TD
><TD
WIDTH="34%"
ALIGN="center"
VALIGN="top"
><A
HREF="custom-scan.html"
ACCESSKEY="U"
>Up</A
></TD
><TD
WIDTH="33%"
ALIGN="right"
VALIGN="top"
>Creating Custom Scan Plans</TD
></TR
></TABLE
></DIV
></BODY
></HTML
>