database/postgres
1
0
Fork 0
mirror of https://github.com/postgres/postgres.git synced 2025-11-07 19:06:32 +03:00
Code Activity

Add support for cross-type hashing in hashed subplans (hashed IN/NOT IN cases

Browse Source 
that aren't turned into true joins).  Since this is the last missing bit of
infrastructure, go ahead and fill out the hash integer_ops and float_ops
opfamilies with cross-type operators.  The operator family project is now
DONE ... er, except for documentation ...
This commit is contained in:
Tom Lane
2007-02-06 02:59:15 +00:00
parent b70e536e4d
commit ab05eedecc
11 changed files with 219 additions and 72 deletions
Download Patch File Download Diff File Expand all files Collapse all files

19
src/backend/optimizer/plan/subselect.c
View File

@@ -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;

4
src/backend/optimizer/util/pathnode.c
View File

@@ -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