in HEAP btree indexes, the address of a record in memory is part of the
key. So, when inserting many identical keys, the actual btree
shape is defined by how and where records in memory are allocated.

records_in_range uses floats to estimate the size of the chunk of the
btree between min and max records, it depends on the btree shape and,
thus, is not portable either. As are optimizer decisions that are based
on records_in_range estimations, if the number happens to be close
to a tipping point.

as a fix, reduce the number of matching rows, so that even with
system-specific variations the optimizer would still pick the
expected plan.

Fixes heap.heap failure (range vs ALL) on ppc64