|
9 | 9 | * |
10 | 10 | * |
11 | 11 | * IDENTIFICATION |
12 | | - * $Header: /cvsroot/pgsql/src/backend/optimizer/path/indxpath.c,v 1.87 2000/07/13 05:47:29 tgl Exp $ |
| 12 | + * $Header: /cvsroot/pgsql/src/backend/optimizer/path/indxpath.c,v 1.88 2000/07/25 04:30:42 tgl Exp $ |
13 | 13 | * |
14 | 14 | *------------------------------------------------------------------------- |
15 | 15 | */ |
@@ -461,9 +461,11 @@ extract_or_indexqual_conditions(RelOptInfo *rel, |
461 | 461 | * Returns a list of all the RestrictInfo nodes for clauses that can be |
462 | 462 | * used with this index. |
463 | 463 | * |
464 | | - * The list is ordered by index key (but as far as I can tell, this is |
465 | | - * an implementation artifact of this routine, and is not depended on by |
466 | | - * any user of the returned list --- tgl 7/99). |
| 464 | + * The list is ordered by index key. (This is not depended on by any part |
| 465 | + * of the planner, as far as I can tell; but some parts of the executor |
| 466 | + * do assume that the indxqual list ultimately delivered to the executor |
| 467 | + * is so ordered. One such place is _bt_orderkeys() in the btree support. |
| 468 | + * Perhaps that ought to be fixed someday --- tgl 7/00) |
467 | 469 | * |
468 | 470 | * Note that in a multi-key index, we stop if we find a key that cannot be |
469 | 471 | * used with any clause. For example, given an index on (A,B,C), we might |
|