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

From Tom Lane
Subject Re: Propose a new hook for mutating the query bounds
Date
Msg-id 2414428.1637160598@sss.pgh.pa.us
Whole thread Raw
In response to Re: Propose a new hook for mutating the query bounds  (Xiaozhe Yao <askxzyao@gmail.com>)
Responses Re: Propose a new hook for mutating the query bounds
List pgsql-hackers
Xiaozhe Yao <askxzyao@gmail.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



pgsql-hackers by date:

Previous
From: vignesh C
Date:
Subject: Re: Printing backtrace of postgres processes
Next
From: Andrew Dunstan
Date:
Subject: Re: pg_upgrade test for binary compatibility of core data types