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

From David Rowley
Subject Don't use bms_membership in places where it's not needed
Date
Msg-id CAApHDvqW+CxNPcY245GaWiuqkkqgTudtG2ncGvvSjGn2wdTZLA@mail.gmail.com
Whole thread Raw
Responses Re: Don't use bms_membership in places where it's not needed
Re: Don't use bms_membership in places where it's not needed
List pgsql-hackers
While working on the patch in [1], I noticed that ever since
00b41463c, it's now suboptimal to do the following:

switch (bms_membership(relids))
{
    case BMS_EMPTY_SET:
       /* handle empty set */
       break;
    case BMS_SINGLETON:
        /* call bms_singleton_member() and handle singleton set */
        break;
    case BMS_MULTIPLE:
       /* handle multi-member set */
       break;
}

The following is cheaper as we don't need to call bms_membership() and
bms_singleton_member() for singleton sets. It also saves function call
overhead for empty sets.

if (relids == NULL)
       /* handle empty set */
else
{
    int relid;

    if (bms_get_singleton(relids, &relid))
        /* handle singleton set */
   else
       /* handle multi-member set */
}

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().

I'm trying to reduce the footprint of what's being worked on in [1]
and I highlighted this as something that'll help with that.

Any objections to me pushing the attached?

David

[1] https://postgr.es/m/CAApHDvqHCNKJi9CrQZG-reQDXTfRWnT5rhzNtDQhnrBzAAusfA@mail.gmail.com

Attachment

pgsql-hackers by date:

Previous
From: Andrei Lepikhov
Date:
Subject: Re: POC PATCH: copy from ... exceptions to: (was Re: VLDB Features)
Next
From: Shlok Kyal
Date:
Subject: Re: undetected deadlock in ALTER SUBSCRIPTION ... REFRESH PUBLICATION