public inbox for [email protected]  
help / color / mirror / Atom feed
From: Andrei Lepikhov <[email protected]>
To: Jakub Wartak <[email protected]>
Cc: Robert Haas <[email protected]>
Cc: [email protected] <[email protected]>
Cc: Tom Lane <[email protected]>
Subject: Re: allowing extensions to control planner behavior
Date: Sat, 19 Oct 2024 07:00:43 +0400
Message-ID: <[email protected]> (raw)
In-Reply-To: <CAKZiRmyZiJbgduUaKJR+vfLDzm-ack+66hVA5Gkj19aLqcgW-g@mail.gmail.com>
References: <CA+TgmoZY+baV-T-5ifDn6P=L=aV-VkVBrPmi0TQkcEq-5Finww@mail.gmail.com>
	<[email protected]>
	<CA+TgmoZQyVxnRU--4g2bJonJ8RyJqNi2CHpy-=nwwBTNpAj71A@mail.gmail.com>
	<CA+TgmoYadvnRGM7VEqgKbuZ+c+VN3jSDx+_38e66a9yk2fiovA@mail.gmail.com>
	<CA+TgmoZ=6jJi9TGyZCm33vads46HFkyz6Aju_saLT6GFS-iFug@mail.gmail.com>
	<[email protected]>
	<CAKZiRmyZiJbgduUaKJR+vfLDzm-ack+66hVA5Gkj19aLqcgW-g@mail.gmail.com>

On 18/10/2024 14:56, Jakub Wartak wrote:
> Hi Andrei,
> 
> On Fri, Oct 11, 2024 at 8:21 AM Andrei Lepikhov <[email protected] 
> <mailto:[email protected]>> 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







view thread (4+ messages)  latest in thread

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected], [email protected], [email protected]
  Subject: Re: allowing extensions to control planner behavior
  In-Reply-To: <[email protected]>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox