]> git.ipfire.org Git - thirdparty/postgresql.git/commit
Fix OR-index-scan planner to recognize that a partial index is usable
authorTom Lane <tgl@sss.pgh.pa.us>
Mon, 11 Oct 2004 22:57:00 +0000 (22:57 +0000)
committerTom Lane <tgl@sss.pgh.pa.us>
Mon, 11 Oct 2004 22:57:00 +0000 (22:57 +0000)
commit26112850ec5733a96a31022859763de4b3724336
tree70a24fd9efb4e4e3792f238b7846fbc2bfd2f6df
parentc0c4883be3bad2d3d760e5cc1d34a2a11a4c8529
Fix OR-index-scan planner to recognize that a partial index is usable
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.
src/backend/optimizer/path/indxpath.c
src/backend/optimizer/path/orindxpath.c
src/include/optimizer/paths.h