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 по дате отправления: