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
