> Hmm, I don't propose modifying costs. The focus is on resetting the plan
> cache decision that PostgreSQL has made in automatic mode. During the
> DBMS operation, various factors may cause a generic plan to be
> suboptimal or make it more desirable as well. Discussions from 2010 to
> 2013 indicate that the community recognised the problem and discovered
> an approach based on execution time and real efforts rather than a
> cost-based method. While I doubt it could be ideal as a core solution,
> an extension may potentially do it for the sake of TPS maximisation.
> What we need is a way to access the plan cache entry.
Thanks for clearing up my understanding. Essentially, override the
current cost-based
method of determining custom vs. generic by using something like execution time,
which is somehow tracked by the extension. That is how I understand this.
Now, I wonder if it may be a good idea to add some hooks in GetCachedPlan
to make this work?
> > Adding CachedPlanSource to QueryDesc seems doable. However, Michael
> > previously objected to adding CachedPlan to QueryDesc. Is there any
> > similar hesitation about including CachedPlanSource?
> I agree that we should investigate further to find the most optimal
> solution. Personally, I'm open to including an internal reference to a
> plan cache entry within the QueryDesc, as long as the plan has its roots
> there.
For the sake of this feature, I suspect making CachedPlanSource available
in QueryDesc will be a non-starter, but I would like to hear other opinions.
To accomplish the goals of this patch, we definitely need the current
execution’s
"plan cache mode" to be accessible in ExecutorEnd somehow.
Since carrying over the plan cache structures to QueryDesc does not seem
suitable, I wonder if the solution used in v11 is better. In v11, the plan cache
mode is tracked in both CachedPlan and QueryDesc, and CachedPlan is passed
to CreateQueryDesc. At this point, the value is set and made available to the
executor hooks.
I also want to note that we need to track the possible values in an enum with
three states: two for custom or generic, and one for an unset mode.
The unset mode
is necessary to allow an extension to determine whether a plan cache
was actually
used or not.
For pg_stat_statements, only pg_stat_statements.c was modified, and I
added tests
for extended query protocol.
--
Sami
