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
