Re: Propose a new hook for mutating the query bounds

On 11/17/21 16:39, Xiaozhe Yao wrote:
> Hi Tom,
> 
> Thanks for your feedback. I completely agree with you that a 
> higher-level hook is better suited for this case. I have adjusted the 
> PoC patch to this email.
> 
> Now it is located in the clauselist_selectivity_ext function, where we 
> first check if the hook is defined. If so, we let the hook estimate the 
> selectivity and return the result. With this one, I can also develop 
> extensions to better estimate the selectivity.
> 

I think clauselist_selectivity is the right level, because this is 
pretty similar to what extended statistics are doing. I'm not sure if 
the hook should be called in clauselist_selectivity_ext or in the plain 
clauselist_selectivity. But it should be in clauselist_selectivity_or 
too, probably.

The way the hook is used seems pretty inconvenient, though. I mean, if 
you do this

     if (clauselist_selectivity_hook)
         return clauselist_selectivity_hook(...);

then what will happen when the ML model has no information applicable to 
a query? This is called for all relations, all conditions, etc. and 
you've short-circuited all the regular code, so the hook will have to 
copy all of that. Seems pretty silly and fragile.

IMO the right approach is what statext_clauselist_selectivity is doing, 
i.e. estimate clauses, mark them as estimated in a bitmap, and let the 
rest of the existing code take care of the remaining clauses. So more 
something like

     if (clauselist_selectivity_hook)
         s1 *= clauselist_selectivity_hook(..., &estimatedclauses);


regards

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