David Rowley <dgrowleyml@gmail.com> writes:
> I'm fine with this one as it's the same as what I already mentioned
> earlier. I had imagined doing bms_del_member(bms_copy ... but maybe
> the compiler is able to optimise away the additional store. Likely, it
> does not matter much as pallocing memory likely adds far more overhead
> anyway.
I actually wrote it that way to start with, but undid it after
noticing that the existing code in remove_rel_from_restrictinfo
does it in separate steps, and thinking that that was good for
both separation of concerns and a cleaner git history. I too
can't believe that an extra fetch will be noticeable compared
to the cost of the adjacent bms_xxx operations.
regards, tom lane
