Re: Don't use bms_membership in places where it's not needed - Mailing list pgsql-hackers

From Richard Guo
Subject Re: Don't use bms_membership in places where it's not needed
Date
Msg-id CAMbWs4_bjaex6RSFAHHJoUsHUv_V76wr6SFKW7NkBVKgbfcQvg@mail.gmail.com
Whole thread Raw
In response to Don't use bms_membership in places where it's not needed  (David Rowley <dgrowleyml@gmail.com>)
Responses Re: Don't use bms_membership in places where it's not needed
List pgsql-hackers

On Fri, Nov 24, 2023 at 12:06 PM David Rowley <dgrowleyml@gmail.com> wrote:
In the attached, I've adjusted the code to use the latter of the two
above methods in 3 places.  In examine_variable() this reduces the
complexity of the logic quite a bit and saves calling bms_is_member()
in addition to bms_singleton_member().

+1 to the idea.

I think you have a typo in distribute_restrictinfo_to_rels.  We should
remove the call of bms_singleton_member and use relid instead.

--- a/src/backend/optimizer/plan/initsplan.c
+++ b/src/backend/optimizer/plan/initsplan.c
@@ -2644,7 +2644,7 @@ distribute_restrictinfo_to_rels(PlannerInfo *root,
             * There is only one relation participating in the clause, so it
             * is a restriction clause for that relation.
             */
-           rel = find_base_rel(root, bms_singleton_member(relids));
+           rel = find_base_rel(root, relid);

Thanks
Richard

pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: [PATCH] fix race condition in libpq (related to ssl connections)
Next
From: Давыдов Виталий
Date:
Subject: Re: How to accurately determine when a relation should use local buffers?