Robert Haas <robertmh...@gmail.com> writes: > I agree. My question is: why shouldn't every case where we can deduce > an implied inequality be reasonably likely to show a benefit?
Maybe it will be, if we can deal with the issue you already mentioned about not misestimating the resulting partially-redundant conditions. > Second, it looks to me like the patch takes the rather naive strategy > of enforcing the derived clauses everywhere that they can legally be > put, which seems certain not to be optimal. I'm not sure about that ... it's basically what we do with derived equalities. However, there's enough structure in the equivalence-class case that we don't end up enforcing redundant quals. It's not clear to me whether the same can be said here. > I don't know whether attaching something to the equivalence class data > structure is the right idea or not. Presumably, we don't want to make > an extra pass over the query tree to gather the information needed for > this kind of optimization, and it feels like we need to know which > vars are EMs before we try to derive alternate/additional quals. Yeah, we don't want to make an additional pass over the tree, and we also would rather not add an additional set of per-operator catalog lookups. We might be able to generalize the code that looks for equality operators so that it looks for "any btree operator" with the same number of lookups, and then have it feed the results down either the EquivalenceClass path or the inequality path as appropriate. At the end, after we've formed all the ECs, we could have a go at matching up the inequality structures with the ECs. But I don't agree that ECs are a necessary prerequisite. Here are a couple of other patterns that might be worth looking for: * "a > b AND b > c" allows deducing "a > c", whether or not any of those values appears in an EC. * "a > const1 AND a > const2" can be simplified to either "a > const1" or "a > const2" depending on which constant is larger. (The predicate proof mechanism already has a form of this, but we don't typically apply it in a way that would result in dropping the redundant qual.) It's entirely possible that one or both of these patterns is not worth looking for. But I would say that it's equally unproven that deriving "a > c" from "a = b AND b > c" is worth the cycles. I'll grant that it's most likely going to be a win if we can use any of these patterns to generate a restriction clause from what had been join clauses. Beyond that it's much less clear. regards, tom lane