26112850ec
for scanning one term of an OR clause if the index's predicate is implied by that same OR clause term (possibly in conjunction with top-level WHERE clauses). Per recent example from Dawid Kuroczko, http://archives.postgresql.org/pgsql-performance/2004-10/msg00095.php Also, fix a very long-standing bug in index predicate testing, namely the bizarre ordering of decomposition of predicate and restriction clauses. AFAICS the correct way is to break down the predicate all the way, and then for each component term see if you can prove it from the entire restriction set. The original coding had a purely-implementation-artifact distinction between ANDing at the top level and ANDing below that, and proceeded to get the decomposition order wrong everywhere below the top level, with the result that even slightly complicated AND/OR predicates could not be proven. For instance, given create index foop on foo(f2) where f1=42 or f1=1 or (f1 = 11 and f2 = 55); the old code would fail to match this index to the query select * from foo where f1 = 11 and f2 = 55; when it obviously ought to match. |
||
|---|---|---|
| .. | ||
| Makefile | ||
| allpaths.c | ||
| clausesel.c | ||
| costsize.c | ||
| indxpath.c | ||
| joinpath.c | ||
| joinrels.c | ||
| orindxpath.c | ||
| pathkeys.c | ||
| tidpath.c | ||