Re: allowing extensions to control planner behavior

On 18/10/2024 14:56, Jakub Wartak wrote:
> Hi Andrei,
> 
> On Fri, Oct 11, 2024 at 8:21 AM Andrei Lepikhov <lepihov@gmail.com 
> <mailto:lepihov@gmail.com>> wrote:
> 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.
Generally, a hash value doesn't 100% guarantee the uniqueness of a node 
identification. Also, RelOptInfo corresponds to a subtree in the final 
plan, and sometimes, it takes work to find which node in the partially 
executed plan corresponds to this specific estimation on row number 
during selectivity estimation. Remember parameterised paths - you should 
attach some signature for each path. So, it is not fully strict method.
If you are interested, I can perhaps explain the method a little bit 
more at some meetup.

> 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)
I argued a lot about allowing extensions to provide separate query_ids 
and came up with the patch a year ago. But it needs more debate on use 
cases - my use cases are primarily from enterprise-grade closed 
extensions, and it doesn't convince anyone. Also, I think any query_id 
should be generated, likewise the core-made one. Does it seem like an 
extensible Perl script?

-- 
regards, Andrei Lepikhov