Home Explore Blog CI



postgresql

3rd chunk of `doc/src/sgml/pgoverexplain.sgml`
d135975727526d6e4120d2a76ac355d281c939fa6c1643cf0000000100000c9c
 Parameter Types</literal>. Type OID for each executor parameter
     (e.g. when a nested loop is chosen and a parameter is used to pass a value down
     to an inner index scan). Does not include parameters supplied to a prepared
     statement by the user.
    </para>
   </listitem>

   <listitem>
    <para>
     <literal>Parse Location</literal>. Location within the query string
     supplied to the planner where this query's text can be found. May be
     <literal>Unknown</literal> in some contexts. Otherwise, may be
     <literal>NNN to end</literal> for some integer <literal>NNN</literal> or
     <literal>NNN for MMM bytes</literal> for some integers
     <literal>NNN</literal> and <literal>MMM</literal>.
    </para>
   </listitem>
  </itemizedlist>
 </sect2>

 <sect2 id="pgoverexplain-range-table">
  <title>EXPLAIN (RANGE_TABLE)</title>

  <para>
   The <literal>RANGE_TABLE</literal> option displays information from the
   plan tree specifically concerning the query's range table. Range table
   entries correspond roughly to items appearing in the query's
   <literal>FROM</literal> clause, but with numerous exceptions. For example,
   subqueries that are proved unnecessary may be deleted from the range table
   entirely, while inheritance expansion adds range table entries for child
   tables that are not named directly in the query.
  </para>

  <para>
   Range table entries are generally referenced within the query plan by a
   range table index, or RTI. Plan nodes that reference one or more RTIs will
   be labelled accordingly, using one of the following fields: <literal>Scan
   RTI</literal>, <literal>Nominal RTI</literal>, <literal>Exclude Relation
   RTI</literal>, <literal>Append RTIs</literal>.
  </para>

  <para>
   In addition, the query as a whole may maintain lists of range table indexes
   that are needed for various purposes. These lists will be displayed once
   per query, labelled as appropriate as <literal>Unprunable RTIs</literal> or
   <literal>Result RTIs</literal>. In text mode, these fields are only
   displayed if they are non-empty sets.
  </para>

  <para>
   Finally, but most importantly, the <literal>RANGE_TABLE</literal> option
   will display a dump of the query's entire range table. Each range table
   entry is labelled with the appropriate range table index, the kind of range
   table entry (e.g.  <literal>relation</literal>,
   <literal>subquery</literal>, or <literal>join</literal>), followed by the
   contents of various range table entry fields that are not normally part of
   <literal>EXPLAIN</literal> output. Some of these fields are only displayed
   for certain kinds of range table entries. For example,
   <literal>Eref</literal> is displayed for all types of range table entries,
   but <literal>CTE Name</literal> is displayed only for range table entries
   of type <literal>cte</literal>.
  </para>

  <para>
   For more information about range table entries, see the definition of
   <literal>RangeTblEntry</literal> in <literal>nodes/plannodes.h</literal>.
  </para>
 </sect2>

 <sect2 id="pgoverexplain-author">
  <title>Author</title>

  <para>
   Robert Haas <email>rhaas@postgresql.org</email>
  </para>
 </sect2>

</sect1>

Title: EXPLAIN (RANGE_TABLE) Option in pg_overexplain Extension
Summary
The RANGE_TABLE option in pg_overexplain provides detailed information about the query's range table. Range table entries correspond to items in the FROM clause, with some exceptions. The output includes range table indexes (RTIs) referenced by plan nodes, lists of RTIs needed for various purposes, and a comprehensive dump of the entire range table. Each entry in the range table dump is labeled with its index, type, and various fields specific to the entry type. This option offers in-depth insights into the query structure and is particularly useful for advanced query analysis and debugging.