Re: Self contradictory examining on rel's baserestrictinfo

Поиск
Список
Период
Сортировка
От Peter Geoghegan
Тема Re: Self contradictory examining on rel's baserestrictinfo
Дата
Msg-id CAH2-Wzk4Sga+c63MC45V0QX_ZchPa-pMjcTDswve9z7Kq=6gTw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Self contradictory examining on rel's baserestrictinfo  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: Self contradictory examining on rel's baserestrictinfo
Список pgsql-hackers
On Mon, Nov 25, 2024 at 3:55 PM Robert Haas <robertmhaas@gmail.com> wrote:
> There are cases where we don't already draw the necessary conclusions,
> such as a>1 and a>2, which could be simplified to a>2. But those cases
> aren't necessarily that common.

Actually, we do use the more restrictive operator with cases like "a>1
and a>2" -- but only in contexts that happen to involve a B-Tree index
scan, where _bt_preprocess_keys gets called. So it's a bit hit or
miss.

Tom has in the past expressed an interesting in moving the stuff in
_bt_preprocess_keys into the planner:

https://www.postgresql.org/message-id/2587523.1647982549@sss.pgh.pa.us

Note that almost nothing in _bt_preprocess_keys is particularly
related to nbtree itself, except perhaps for the stuff that marks scan
keys required. The fact that "WHERE a IN (1, 2, 3) AND a < 2" can
actually be simplified to "WHERE a = 1" has exactly nothing to do with
B-Tree index scans, but we'll only do this simplification in the
context of a B-Tree index scan. There is also some redundancy between
_bt_preprocess_keys and the planner, which is less than ideal.

--
Peter Geoghegan



В списке pgsql-hackers по дате отправления: