Re: allowing extensions to control planner behavior

Hi Andrei,

On Fri, Oct 11, 2024 at 8:21 AM Andrei Lepikhov <lepihov(at)gmail(dot)com> wrote:

> On 10/10/24 23:51, Robert Haas wrote:
> > On Wed, Sep 18, 2024 at 11:48 AM Robert Haas <robertmhaas(at)gmail(dot)com>
> wrote:
> > 1. If you want to specify in-query hints using comments, how does your
> > extension get access to the comments?
> Having designed two features [1,2] that do the stuff mostly similar to
> pg_hint_plan but based on real cardinalities earned from previous
> executions, I can say the most annoying problem is hinting subqueries &
> CTEs. Sometimes, you want to hint at the top query and not touch the
> subquery and vice versa. Sometimes, users get stuck in accidents when a
> flattened subquery influences your hint. So, the key property to invent
> in advance should be an identification system.
> I have chosen hash-based identification when each RelOptInfo has a hash
> created over values of relids, restrictions and hashes of underlying
> RelOptInfos. At the core, it seems inappropriate.
>

out of curiosity, why do You think it would be inappropriate to do so in
the core? Maybe it Is something similiar to compute_query_id that can be
computed externally too. I remember Tom arguing that query_id should be
computed externally by extension for some reasons because each extension
may want differently to fingerprint the queries, but I cannot find link to
discussion now or bring more details)

-J.