On Sat, Nov 29, 2014 at 8:18 AM, Tom Lane wrote:
> David Rowley writes:
> > A while back when I was benchmarking the planner time during my trials
> with
> > anti/semi join removals, I wrote a patch to change the usage pattern for
> > cases such as:
>
> > if (bms_membership(a) != BMS_SINGLETON)
David Rowley writes:
> A while back when I was benchmarking the planner time during my trials with
> anti/semi join removals, I wrote a patch to change the usage pattern for
> cases such as:
> if (bms_membership(a) != BMS_SINGLETON)
> return; /* nothing to do */
> singleton = bms_singleton_memb
David Rowley writes:
> I have to say I don't really like the modifying of the loop iterator that's
> going on here:
> col = -1;
> while ((col = bms_next_member(rte->modifiedCols, col)) >= 0)
> {
> col += FirstLowInvalidHeapAttributeNumber;
> /* do stuff */
> col -= FirstLowInvalidHeapAttrib
Dean Rasheed writes:
> On 27 November 2014 at 19:20, Tom Lane wrote:
>> The attached proposed patch adds bms_next_member() and replaces
>> bms_first_member() calls where it seemed to make sense.
> There is another micro-optimisation that you could make in
> bms_next_member() -- it isn't necessar
On Fri, Nov 28, 2014 at 8:20 AM, Tom Lane wrote:
>
> The attached proposed patch adds bms_next_member() and replaces
> bms_first_member() calls where it seemed to make sense. I've had a
> hard time measuring much speed difference for this patch in isolation,
> but in principle it should be less
On 27 November 2014 at 19:20, Tom Lane wrote:
> The attached proposed patch adds bms_next_member() and replaces
> bms_first_member() calls where it seemed to make sense. I've had a
> hard time measuring much speed difference for this patch in isolation,
> but in principle it should be less code a
