Two comments: First: on our side, we’d like to know if *removing* the use of this predicate pullup information would have *negative* consequences for correctness. If it does not impact correctness: we can override the behavior to not consider this information, and move forwards.
Second: a colleague pointed out that join’s notion of unique may also be too conservative, depending on what RelMdColumnUniqueness.areColumnsUnique is really supposed to be doing. If the intention is to check if the bitset of columns forms a unique key, then the join analysis is too conservative, since if there are unique columns from one side, and non-unique from the other, the whole key is considered not unique, even though the presence of *any* unique column makes the overall key unique. (Its worth pointing out that this is how Statisitcs.isKey works, which is how areColumnsUnique(TableScan) works if that RelOptTable does not provide a special uniqueness handler). If the intention is to check if *any* column in the bitset is itself unique, then the join analysis is also too conservative, for the same reasons. If the intention is to check if *all* column in the bitset is itself unique, then the join analysis is fine but the TableScan’s default analysis is incorrect (for reasons mentioned above). So there’s more than just this predicate pullup at play here.
