From: | Jerry Brenner <jbrenner(at)guidewire(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-performance(at)lists(dot)postgresql(dot)org |
Subject: | Re: Is there a way to identify a plan generated by GECO? |
Date: | 2025-07-18 13:20:03 |
Message-ID: | CACoKFYQBVOmU3gRvmYhvBzSFTef02eMbn6ejxeR0sf5vSzbn4g@mail.gmail.com |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
We just jdbc and bind variables, so we are using PreparedStatements.
plan_cache_mode is set to auto
So, it sounds like there could be plan caching. (I wasn't aware of that.)
Is there any kind of running counter in a system view that tracks the
number of executions of cached plans?
We are capturing the plans via auto_explain and limited to the explain
options available with that path. Is there anything in the plan that would
tell us if the execution used a cached plan? (My manual explains does not
use a prepare.)
Thanks, Jerry
On Thu, Jul 17, 2025 at 8:10 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Jerry Brenner <jbrenner(at)guidewire(dot)com> writes:
> > I don't have any background with the randomized search. Does the
> repeated
> > pattern with the same plan being executed multiple times in a time range
> > and then the plan changes, never to change back, match the expectation
> with
> > the randomization?
>
> [ shrug... ] Insufficient information. There could be some plan
> caching going on that contributes to this effect, though.
>
> regards, tom lane
>
>
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2025-07-18 21:54:05 | Re: Poor row estimates from planner, stat `most_common_elems` sometimes missing for a text[] column |
Previous Message | Tom Lane | 2025-07-18 03:10:21 | Re: Is there a way to identify a plan generated by GECO? |