1
0
mirror of https://github.com/postgres/postgres.git synced 2026-10-23 13:29:09 +03:00

doc: Note that plan advice does not affect cached plans

Plan advice is consulted only at plan time.  When a cached plan is
re-executed, no re-planning occurs, so updated advice has no effect.
DISCARD PLANS can be used to discard cached plans, but only affects
the sessions in which it is executed.

Reported-by: Noah Misch <noah@leadboat.com>
Suggested-by: Jakub Wartak <jakub.wartak@enterprisedb.com>
Discussion: https://postgr.es/m/20260827171830.68.noahmisch@microsoft.com
Co-authored-by: Dongpo Liu <poe.liu@pm.me>
Co-authored-by: Robert Haas <rhaas@postgresql.org>
Backpatch-through: 19
This commit is contained in:
Robert Haas
2026-10-16 17:22:33 -04:00
parent c705304a0f
commit a69ac35598
2 changed files with 20 additions and 0 deletions

View File

@@ -827,6 +827,18 @@ EXPLAIN (COSTS OFF)
Note that scan advice is not affected by this limitation because it does
not constrain the join order.
</para>
<para>
Plan advice is consulted only when a query is planned. If a prepared
statement is re-executed under a different value of
<varname>pg_plan_advice.advice</varname>, or with different advice supplied
by another module such as <xref linkend="pgstashadvice"/>, it can still
make use of a previously cached plan. The same thing can happen when
re-executing a statement within a <application>PL/pgSQL</application>
block, where plans can also be cached. Sessions that do not wish to reuse
previously-cached plans can use
<link linkend="sql-discard"><command>DISCARD PLANS</command></link>.
</para>
</sect2>
<sect2 id="pgplanadvice-author">

View File

@@ -65,6 +65,14 @@
<literal>pg_stash_advice</literal> will enable it automatically.
</para>
<para>
Stashed advice is applied only when a query is planned. Adding, replacing,
or removing a stash entry, or changing
<literal>pg_stash_advice.stash_name</literal>, does not affect plans that
have already been cached. See
<xref linkend="pgplanadvice-limitations"/>.
</para>
<para>
Generally, the fact that the planner is able to change query plans as
the underlying distribution of data changes is a feature, not a bug.