From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Sami Imseih <samimseih(at)gmail(dot)com> |
Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: should num_custom_plans be reset after plan invalidation? |
Date: | 2025-03-05 14:52:46 |
Message-ID: | 304268.1741186366@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Sami Imseih <samimseih(at)gmail(dot)com> writes:
> While examining plan caches, I noticed that when a generic plan is invalidated,
> the next execution of the prepared statement still results in a
> generic plan. This
> is of course with the default plan_cache_mode.
> This behavior might go unnoticed since plan cache invalidations are
> relatively uncommon,
> but I’m unsure if this is the intended design.
Yes, it is. There's little reason to expect that the invalidation
would change our decision, and re-planning five times to confirm that
is a high price to pay.
Sure, the invalidation *might* have been because of a new index
that happens to fit the query, but the odds of that seem small to me.
It's much more likely because of auto-vacuum tweaking the stats, or
just a random sinval queue overrun.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Nazir Bilal Yavuz | 2025-03-05 14:57:17 | Upgrade FreeBSD CI images to 14.2 |
Previous Message | Israel Barth Rubio | 2025-03-05 14:47:33 | Re: Add -k/--link option to pg_combinebackup |