Re: Self contradictory examining on rel's baserestrictinfo - Mailing list pgsql-hackers

From Peter Geoghegan
Subject Re: Self contradictory examining on rel's baserestrictinfo
Date
Msg-id CAH2-Wzk4Sga+c63MC45V0QX_ZchPa-pMjcTDswve9z7Kq=6gTw@mail.gmail.com
Whole thread Raw
In response to Re: Self contradictory examining on rel's baserestrictinfo  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: Self contradictory examining on rel's baserestrictinfo
List 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 by date:

Previous
From: Nathan Bossart
Date:
Subject: Re: Use __attribute__((target(sse4.2))) for SSE42 CRC32C
Next
From: Masahiko Sawada
Date:
Subject: Re: Skip collecting decoded changes of already-aborted transactions