diff options
Diffstat (limited to 'src/backend/optimizer')
| -rw-r--r-- | src/backend/optimizer/plan/subselect.c | 19 | ||||
| -rw-r--r-- | src/backend/optimizer/util/pathnode.c | 4 |
2 files changed, 9 insertions, 14 deletions
diff --git a/src/backend/optimizer/plan/subselect.c b/src/backend/optimizer/plan/subselect.c index 7339445e046..e79991a0f60 100644 --- a/src/backend/optimizer/plan/subselect.c +++ b/src/backend/optimizer/plan/subselect.c @@ -7,7 +7,7 @@ * Portions Copyright (c) 1994, Regents of the University of California * * IDENTIFICATION - * $PostgreSQL: pgsql/src/backend/optimizer/plan/subselect.c,v 1.117 2007/01/10 18:06:03 tgl Exp $ + * $PostgreSQL: pgsql/src/backend/optimizer/plan/subselect.c,v 1.118 2007/02/06 02:59:11 tgl Exp $ * *------------------------------------------------------------------------- */ @@ -598,17 +598,13 @@ subplan_is_hashable(SubLink *slink, SubPlan *node) return false; /* - * The combining operators must be hashable, strict, and self-commutative. + * The combining operators must be hashable and strict. * The need for hashability is obvious, since we want to use hashing. * Without strictness, behavior in the presence of nulls is too - * unpredictable. (We actually must assume even more than plain - * strictness, see nodeSubplan.c for details.) And commutativity ensures - * that the left and right datatypes are the same; this allows us to - * assume that the combining operators are equality for the righthand - * datatype, so that they can be used to compare righthand tuples as well - * as comparing lefthand to righthand tuples. (This last restriction - * could be relaxed by using two different sets of operators with the hash - * table, but there is no obvious usefulness to that at present.) + * unpredictable. We actually must assume even more than plain + * strictness: they can't yield NULL for non-null inputs, either + * (see nodeSubplan.c). However, hash indexes and hash joins assume + * that too. */ if (IsA(slink->testexpr, OpExpr)) { @@ -644,8 +640,7 @@ hash_ok_operator(OpExpr *expr) if (!HeapTupleIsValid(tup)) elog(ERROR, "cache lookup failed for operator %u", opid); optup = (Form_pg_operator) GETSTRUCT(tup); - if (!optup->oprcanhash || optup->oprcom != opid || - !func_strict(optup->oprcode)) + if (!optup->oprcanhash || !func_strict(optup->oprcode)) { ReleaseSysCache(tup); return false; diff --git a/src/backend/optimizer/util/pathnode.c b/src/backend/optimizer/util/pathnode.c index 5832d145ef0..81f7c99e963 100644 --- a/src/backend/optimizer/util/pathnode.c +++ b/src/backend/optimizer/util/pathnode.c @@ -8,7 +8,7 @@ * * * IDENTIFICATION - * $PostgreSQL: pgsql/src/backend/optimizer/util/pathnode.c,v 1.137 2007/01/20 20:45:39 tgl Exp $ + * $PostgreSQL: pgsql/src/backend/optimizer/util/pathnode.c,v 1.138 2007/02/06 02:59:12 tgl Exp $ * *------------------------------------------------------------------------- */ @@ -1070,7 +1070,7 @@ distinct_col_search(int colno, List *colnos, List *opids) * We assume hashed aggregation will work if each IN operator is marked * hashjoinable. If the IN operators are cross-type, this could conceivably * fail: the aggregation will need a hashable equality operator for the RHS - * datatype --- but it's pretty hard to conceive of a hash opclass that has + * datatype --- but it's pretty hard to conceive of a hash opfamily that has * cross-type hashing without support for hashing the individual types, so * we don't expend cycles here to support the case. We could check * get_compatible_hash_operator() instead of just op_hashjoinable(), but the |