Re: pg_*_advice: tsv load failure, etc.

From: Jakub Wartak <jakub(dot)wartak(at)enterprisedb(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Noah Misch <noah(at)leadboat(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: pg_*_advice: tsv load failure, etc.
Date: 2026-08-31 13:25:16
Message-ID: CAKZiRmwL6coBp3cLnwHDZHo6Gpk_sh_eS8OYjJRS3p+PBojY=Q@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Aug 28, 2026 at 4:21 PM Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>
>
> > ### 5. pg_plan_advice.advice / stash advice changes are silently ignored by an already-cached generic plan
>
> This is a planner control feature; it does not affect behavior other
> than at plan time. I don't see that as a bug. That said, I think it
> would be perfectly valid for someone to try to figure a way for advice
> stash changes to invalidate plans, but I suspect that will require
> significant new infrastructure. Plan invalidation is generally tied to
> catalog modifications, and here we would instead want to tie it to a
> plan ID. We could do that by adding a custom invalidation type to
> sinval.h just for the use of pg_stash_advice, but would be a pretty
> serious piece of core infrastructure for an as-yet-unproven contrib
> module to use to solve a problem which (for all we know now) may have
> little practical impact.

FWIW, this was already discussed back in the day I think in [1]. I wouldn't
remeber it otherwise if not the mailing list, but apparently ANALYZE on the
table affected was enough to trigger the change [2]. Perhaps adding one
statement to the docs would be good enough to cover it for now, like: "In
order to change the already cached plans, issue ANALYZE on relevant tables."
(because apparently without it it now confused 2 people and 1 AI ;))

-J.

[1] - https://www.postgresql.org/message-id/CA%2BTgmoYO0qtqz%2BV7S4q0e_dLhLrrsMxA51t5wks_y8Skv6cdRQ%40mail.gmail.com
[2] - https://www.postgresql.org/message-id/CA%2BTgmob8O4TbZVr2zoqm5m-Zp6fj-8iBh%3D0u-xfiy5Xr5MNFCQ%40mail.gmail.com

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Matthias van de Meent 2026-08-31 13:29:32 Re: SQL-level pg_datum_image_equal
Previous Message Bertrand Drouvot 2026-08-31 13:24:06 Re: pgstat: Flush some statistics within running transactions, take 2