From: | Peter Geoghegan <pg(at)bowt(dot)ie> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | ro b <bigbro_wq(at)hotmail(dot)com>, pgsql-hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Self contradictory examining on rel's baserestrictinfo |
Date: | 2024-11-25 21:06:01 |
Message-ID: | CAH2-Wzk4Sga+c63MC45V0QX_ZchPa-pMjcTDswve9z7Kq=6gTw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, Nov 25, 2024 at 3:55 PM Robert Haas <robertmhaas(at)gmail(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Masahiko Sawada | 2024-11-25 21:28:00 | Re: Skip collecting decoded changes of already-aborted transactions |
Previous Message | Nathan Bossart | 2024-11-25 21:02:54 | Re: Use __attribute__((target(sse4.2))) for SSE42 CRC32C |