| 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
| 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 |