Re: Propose a new hook for mutating the query bounds

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Propose a new hook for mutating the query bounds
Дата
Msg-id 2414428.1637160598@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Propose a new hook for mutating the query bounds  (Xiaozhe Yao <askxzyao@gmail.com>)
Ответы Re: Propose a new hook for mutating the query bounds  (Xiaozhe Yao <askxzyao@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: vignesh C
Дата:
Сообщение: Re: Printing backtrace of postgres processes
Следующее
От: Andrew Dunstan
Дата:
Сообщение: Re: pg_upgrade test for binary compatibility of core data types