Don't use bms_membership in places where it's not needed

Поиск
Список
Период
Сортировка
От David Rowley
Тема Don't use bms_membership in places where it's not needed
Дата
Msg-id CAApHDvqW+CxNPcY245GaWiuqkkqgTudtG2ncGvvSjGn2wdTZLA@mail.gmail.com
обсуждение исходный текст
Ответы 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
Список 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

Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Andrei Lepikhov
Дата:
Сообщение: Re: POC PATCH: copy from ... exceptions to: (was Re: VLDB Features)
Следующее
От: Shlok Kyal
Дата:
Сообщение: Re: undetected deadlock in ALTER SUBSCRIPTION ... REFRESH PUBLICATION