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 hoo
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 applic
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
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 est
Xiaozhe Yao writes:
+ if (mutate_bounds_hook) {
+ mutate_bounds_hook(root, &constval, isgt, iseq);
+ }
It seems unlikely that this could do anything actually useful,
and impossible that it could do anything useful without enormous waste
of cycles along the way. Basical
Hi Tomas and Hackers,
Thanks for your reply and feedback!
> I don't understand how you could achieve this by mutating pg_statistic,
without also breaking estimation for queries that only have Y<20.
I agree, if we mutate pg_statistics, we will break lots of stuff and the
process becomes complicat
On 11/17/21 2:24 PM, Xiaozhe Yao wrote:
> Hi hackers,
>
> I am currently working on improving the cardinality estimation component
> in PostgreSQL with machine learning. I came up with a solution that
> mutates the bounds for different columns. For example, assume that we
> have a query
>
> ``
