So I think knowing what bad it is to have this feature is the key point to discussion now.
> While I've only read your description of the patch not the patch itself,
This comment applies to me also.
Is the join selectivity properly calculated in all cases, e.g. in the n:m join case in particular, or in general when you’re not joining to a unique key? (this would be the usual situation here, since it adds a range qual to a join qual)
>> Furthermore, there are some cases involving parameterized paths where >> enforcing the inequality multiple times is definitely bad
This has been done by committing 4.
What remaining cases are there where the qual is evaluated redundantly?
Anyone still have interest in this? Or is a better solution really possible?
Or is the current method too bad to rescue?
As you’ve shown, this can potentially be very important, though I don’t think you’ll often see equijoins with an additional range restriction on the join keys. When it happens, though, it could be especially important for joins to partitioned tables with many remote fdw partitions when the join can’t be pushed down to the remote server.
