<literal>DEFERRABLE</literal> mode,
   otherwise it is opened in <literal>NOT DEFERRABLE</literal> mode.
  </para>

  <para>
   Note that it is currently not supported by
   <filename>postgres_fdw</filename> to prepare the remote transaction for
   two-phase commit.
  </para>
 </sect2>

 <sect2 id="postgres-fdw-remote-query-optimization">
  <title>Remote Query Optimization</title>

  <para>
   <filename>postgres_fdw</filename> attempts to optimize remote queries to reduce
   the amount of data transferred from foreign servers.  This is done by
   sending query <literal>WHERE</literal> clauses to the remote server for
   execution, and by not retrieving table columns that are not needed for
   the current query.  To reduce the risk of misexecution of queries,
   <literal>WHERE</literal> clauses are not sent to the remote server unless they use
   only data types, operators, and functions that are built-in or belong to an
   extension that's listed in the foreign server's <literal>extensions</literal>
   option.  Operators and functions in such clauses must
   be <literal>IMMUTABLE</literal> as well.
   For an <command>UPDATE</command> or <command>DELETE</command> query,
   <filename>postgres_fdw</filename> attempts to optimize the query execution by
   sending the whole query to the remote server if there are no query
   <literal>WHERE</literal> clauses that cannot be sent to the remote server,
   no local joins for the query, no row-level local <literal>BEFORE</literal> or
   <literal>AFTER</literal> triggers or stored generated columns on the target
   table, and no <literal>CHECK OPTION</literal> constraints from parent
   views.  In <command>UPDATE</command>,
   expressions to assign to target columns must use only built-in data types,
   <literal>IMMUTABLE</literal> operators, or <literal>IMMUTABLE</literal> functions,
   to reduce the risk of misexecution of the query.
  </para>

  <para>
   When <filename>postgres_fdw</filename> encounters a join between foreign tables on
   the same foreign server, it sends the entire join to the foreign server,
   unless for some reason it believes that it will be more efficient to fetch
   rows from each table individually, or unless the table references involved
   are subject to different user mappings.  While sending the <literal>JOIN</literal>
   clauses, it takes the same precautions as mentioned above for the
   <literal>WHERE</literal> clauses.
  </para>

  <para>
   The query that is actually sent to the remote server for execution can
   be examined using <command>EXPLAIN VERBOSE</command>.
  </para>
 </sect2>

 <sect2 id="postgres-fdw-remote-query-execution-environment">
  <title>Remote Query Execution Environment</title>

  <para>
   In the remote sessions opened by <filename>postgres_fdw</filename>,
   the <xref linkend="guc-search-path"/> parameter is set to
   just <literal>pg_catalog</literal>, so that only built-in objects are visible
   without schema qualification.  This is not an issue for queries
   generated by <filename>postgres_fdw</filename> itself, because it always
   supplies such qualification.  However, this can pose a hazard for
   functions that are executed on the remote server via triggers or rules
   on remote tables.  For example, if a remote table is actually a view,
   any functions used in that view will be executed with the restricted
   search path.  It is recommended to schema-qualify all names in such
   functions, or else attach <literal>SET search_path</literal> options
   (see <xref linkend="sql-createfunction"/>) to such functions
   to establish their expected search path environment.
  </para>

  <para>
   <filename>postgres_fdw</filename> likewise establishes remote session settings
   for various parameters:
   <itemizedlist spacing="compact">
    <listitem>
     <para>
      <xref linkend="guc-timezone"/> is set to <literal>UTC</literal>
     </para>
    </listitem>
    <listitem>
     <para>
      <xref linkend="guc-datestyle"/> is set