pgsql: Fix OR-index-scan planner to recognize that a partial index is

Log Message:
-----------
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.

Modified Files:
--------------
pgsql/src/backend/optimizer/path:
indxpath.c (r1.164 -> r1.165)
(http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/optimizer/path/indxpath.c.diff?r1=1.164&r2=1.165)
orindxpath.c (r1.62 -> r1.63)
(http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/optimizer/path/orindxpath.c.diff?r1=1.62&r2=1.63)
pgsql/src/include/optimizer:
paths.h (r1.75 -> r1.76)
(http://developer.postgresql.org/cvsweb.cgi/pgsql/src/include/optimizer/paths.h.diff?r1=1.75&r2=1.76)