Re: Proposal - Allow extensions to set a Plan Identifier

> > but the opposite may be
> > not necessarily true: a query ID could be associated with multiple
> > plan patterns (aka multiple plan IDs).  What this offers is that we
> > know about which plan one query is currently using in live, for a
> > given query ID.
> Okay, as I've said before, it seems practical. I just worry because I
> see that people don't understand that queryId is a more or less
> arbitrary value that may or may not group queries that differ only by
> constants to a single "Query Class". I think the same attitude will be
> paid to planId. It is okay for statistics. However, non-statistical
> extensions need more guarantees and want to put different logic into
> these values.
> For now, we have examples of only statistical extensions in open-source
> and may live with a proposed solution.

statistical/monitoring reasons are an important use case. Detecting plan
changes, load attributed to a specific plan, etc.
However, I also do see other extensions that could implement a plan_id
that has meaning beyond statistical/monitoring purposes.
Plan management/enforcement is another use-case.

> >> So, it seems that extensions may conflict with the same field. Are we sure
> >> that will happen if they are loaded in different orders in neighbouring
> >> backends?
> >
> > Depends on what kind of computation once wants to do, and surely
> > without some coordination across the extensions you are using these
> > cannot be shared, but it's no different from the concept of a query
> > ID.
> Hmm, queryId generation code lies in the core and we already came to
> terms that this field has only a statistical purpose. Do you want to
> commit planId generation code?

But, extensions don't necessarily need to rely on the core queryId. They
can generate their own queryId.
We have it documented for compute_query_id as such [0]
"Note that an external module can alternatively be used if the in-core query
identifier computation method is not acceptable"

[0] https://www.postgresql.org/docs/current/runtime-config-statistics.html#GUC-COMPUTE-QUERY-ID

--
Sami Imseih
Amazon Web Services (AWS)