Re: Propose a new hook for mutating the query bounds - Mailing list pgsql-hackers

From Tomas Vondra
Subject Re: Propose a new hook for mutating the query bounds
Date
Msg-id d2759af9-3675-5c1e-9b86-4ddb1935db45@enterprisedb.com
Whole thread Raw
In response to Re: Propose a new hook for mutating the query bounds  (Xiaozhe Yao <askxzyao@gmail.com>)
List pgsql-hackers
On 11/18/21 10:59, Xiaozhe Yao wrote:
> Hi,
> 
> Thanks for the previous feedbacks!
> 
>  > The way the hook is used seems pretty inconvenient, though.
> 
> I see the problem, and I agree.
> 
> I looked into how other hooks work, and I am wondering if it looks ok if 
> we: pass a pointer to the hook, and let the hook check if there is any 
> information applicable. If there is none, the hook just returns False 
> and we let the rest of the code handle. If it is true, we get the 
> selectivity from the hook and return it. So something like
> 
> ```
> if (clauselist_selectivity_hook &&
> (*clauselist_selectivity_hook) (root, clauses, varRelid, jointype, 
> sjinfo, use_extended_stats, &s1))
> {
> return s1;
> }
> ```
> 

No, that doesn't really solve the issue, because it's all or nothing 
approach. What if you ML can help estimating just a subset of clauses? 
IMHO the hooks should allow estimating the clauses the ML model was 
built on, and then do the usual estimation for the remaining ones. 
Otherwise you still have to copy large parts of the code.

> What I am trying to mock is the get_index_stats_hook 
> (https://github.com/taminomara/psql-hooks/blob/master/Detailed.md#get_index_stats_hook 
> <https://github.com/taminomara/psql-hooks/blob/master/Detailed.md#get_index_stats_hook>). 
> 

But that hook only deals with a single index at a time - either it finds 
stats for it or not. But this new hook deals with a list of clauses, it 
should allow processing just a subset of them, I think.


regards

-- 
Tomas Vondra
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



pgsql-hackers by date:

Previous
From: Masahiko Sawada
Date:
Subject: Re: Skipping logical replication transactions on subscriber side
Next
From: Alexander Kuzmenkov
Date:
Subject: [RFC] ASOF Join