From: | b ro <bigbro_wq(at)hotmail(dot)com> |
---|---|
To: | pgsql-hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | 回复: bt Scankey in another contradictory case |
Date: | 2024-08-30 08:27:44 |
Message-ID: | TYWPR01MB92786547D345C7529DE7F28985972@TYWPR01MB9278.jpnprd01.prod.outlook.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
this is the patch attachment.
________________________________
发件人: b ro <bigbro_wq(at)hotmail(dot)com>
发送时间: 2024年8月30日 0:56
收件人: pgsql-hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
主题: bt Scankey in another contradictory case
Hi,
when i read source code of the part of nbtree, i detected another kind of contradictory case postgresql has not eliminated
(eg. x >4 and x <3) in the function _bt_preprocess_keys in nbtutils.c. this cause next unnecessary index scan and qual evaluation.
it seems no one will write SQL like that, but maybe it generated from the ec or degenerate qual.
the function just invoked in function _bt_first during initializing index scan, so it’s cheap to eliminate this case in the function.
we just pay attention on the opposite operator, so there are four detailed cases (ie. x >4 and x <3 , x >4 and x <=3, x >=4 and x <3, x >=4 and x <=3).
when test the case is contradictory or not, it's need to use the more restrictive operator when less and more restrictive operator both appeared,
case like x >4 and x <=4, if we choose <=, 4 <= 4 is satisfied, actually x >4 and x <=4 is contradictory.
when >= with <= or > with <, it's ok to pick any one of them.
i have added this feature in my local environment and tested. but i am not sure it's worth to spend more effort on it.
________________________________
bigbro_wq(at)hotmail(dot)com
Attachment | Content-Type | Size |
---|---|---|
patch.diff | application/octet-stream | 2.1 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | shveta malik | 2024-08-30 08:35:50 | Re: Collect statistics about conflicts in logical replication |
Previous Message | Michael Paquier | 2024-08-30 08:24:19 | Re: Sequence Access Methods, round two |