On Mon, Nov 5, 2012 at 3:07 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Robert Haas <robertmh...@gmail.com> writes: >> On Mon, Nov 5, 2012 at 2:44 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: >>> Um, no. This is a useful counterexample: >>> WHERE t.a > x.c1 AND t.a < y.c2 > >> Well, OK. So maybe you also need the operator to be the same as well. > > Nope. A counterexample to that claim is a GIN index on an array column: > > WHERE t.arraycol @> array[1,2,3] AND t.arraycol @> array[4,5,6] > > This restriction is equivalent to > > WHERE t.arraycol @> array[1,2,3,4,5,6] > > which is substantially more selective than either constraint alone. > If the two RHS arrays are not constants, but are coming from different > tables x and y, then we have something isomorphic to the previous > example (at least from the perspective of indxpath.c), but it would > not be good for indxpath.c to assume that these clauses couldn't be > useful together.
Neat example. > We *can* make a simplifying assumption of the kind you suggest when > we know that the clauses were all generated from the same equivalence > class, because then we have very strong assumptions about what the > clauses' semantics are. (And indeed the patch does take care of that > case separately.) But for the general case of non-equijoin clauses > we can't assume very much at all about whether clauses are redundant, > at least not without knowledge that indxpath.c hasn't got. OK. Fortunately, I don't think we need to care too much about that case, since non-equijoins are pretty rare. A reasonable heuristic restriction seems fine for that case ... at least until the next problem case shows up. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
