|
9 | 9 | * |
10 | 10 | * |
11 | 11 | * IDENTIFICATION |
12 | | - * $PostgreSQL: pgsql/src/backend/optimizer/path/indxpath.c,v 1.205 2006/05/1817:12:10 tgl Exp $ |
| 12 | + * $PostgreSQL: pgsql/src/backend/optimizer/path/indxpath.c,v 1.206 2006/05/1819:56:46 tgl Exp $ |
13 | 13 | * |
14 | 14 | *------------------------------------------------------------------------- |
15 | 15 | */ |
@@ -616,10 +616,10 @@ choose_bitmap_and(PlannerInfo *root, RelOptInfo *rel, List *paths) |
616 | 616 | * non-selective. In any case, we'd surely be drastically misestimating |
617 | 617 | * the selectivity if we count the same condition twice. |
618 | 618 | * |
619 | | - *XXX is there any risk of throwing away a useful partial index here |
620 | | - *because we don't explicitly look at indpred? At least in simple cases, |
621 | | - * the partial indexwill sort before competing non-partial indexes and so |
622 | | - *it makes the right choice, but perhaps we need to work harder. |
| 619 | + *We include index predicate conditions in the redundancy test. Because |
| 620 | + *the test is just for pointer equality and not equal(), the effect is |
| 621 | + *that use ofthesamepartial indexin two different AND elements is |
| 622 | + *considered redundant. (XXX is this too strong?) |
623 | 623 | * |
624 | 624 | * Note: outputting the selected sub-paths in selectivity order is a good |
625 | 625 | * thing even if we weren't using that as part of the selection method, |
@@ -732,14 +732,14 @@ bitmap_and_cost_est(PlannerInfo *root, RelOptInfo *rel, List *paths) |
732 | 732 | /* |
733 | 733 | * pull_indexpath_quals |
734 | 734 | * |
735 | | - * Given the Path structure for a plain or bitmap indexscan, extract a |
736 | | - *listofRestrictInfo nodes forall the indexquals used in the Path. |
| 735 | + * Given the Path structure for a plain or bitmap indexscan, extract a list |
| 736 | + * of all the indexquals and index predicate conditions used in the Path. |
737 | 737 | * |
738 | 738 | * This is sort of a simplified version of make_restrictinfo_from_bitmapqual; |
739 | 739 | * here, we are not trying to produce an accurate representation of the AND/OR |
740 | 740 | * semantics of the Path, but just find out all the base conditions used. |
741 | 741 | * |
742 | | - * The result list contains pointers to theRestrictInfos used in the Path, |
| 742 | + * The result list contains pointers to theexpressions used in the Path, |
743 | 743 | * but all the list cells are freshly built, so it's safe to destructively |
744 | 744 | * modify the list (eg, by concat'ing it with other lists). |
745 | 745 | */ |
@@ -777,7 +777,8 @@ pull_indexpath_quals(Path *bitmapqual) |
777 | 777 | { |
778 | 778 | IndexPath*ipath= (IndexPath*)bitmapqual; |
779 | 779 |
|
780 | | -result=list_copy(ipath->indexclauses); |
| 780 | +result=get_actual_clauses(ipath->indexclauses); |
| 781 | +result=list_concat(result,list_copy(ipath->indexinfo->indpred)); |
781 | 782 | } |
782 | 783 | else |
783 | 784 | elog(ERROR,"unrecognized node type: %d",nodeTag(bitmapqual)); |
|