From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Xiaozhe Yao <askxzyao(at)gmail(dot)com> |
Cc: | Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: Propose a new hook for mutating the query bounds |
Date: | 2021-11-17 14:49:58 |
Message-ID: | 2414428.1637160598@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Xiaozhe Yao <askxzyao(at)gmail(dot)com> 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. Basically, each time one calls scalarineqsel,
the hook would have to re-analyze the entire query to see if it should do
anything. Most of the time the answer would be "no", after a lot of
cycles wasted. It would also have to keep some state (where?) to
coordinate mutation of different Consts in a WHERE clause. And why only
a hook in scalarineqsel? Is that really the only context that you'd need
to adjust the results in?
Another important deficiency in this API spec is that the hook has no
idea *which* constant it's being called on, so I don't see how it could
really deliver correct answers at all.
I can buy that ML techniques might provide a way to improve selectivity
estimates overall, but I think inserting them would be better done with
a much higher-level hook, maybe about at the level of
clauselist_selectivity.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Dunstan | 2021-11-17 15:07:17 | Re: pg_upgrade test for binary compatibility of core data types |
Previous Message | Thomas | 2021-11-17 14:45:26 | Re: Patch: Range Merge Join |