Hi Kimon,
There are also distinct hashing and group hashing operators (as well as hash union) , so we're looking at more than hash joins.
..however...
What you said made me think (along with the question in the other forum about the non-ansi group by query)
It is possible for a hash join to satisfy having clause in a non-ansi group by query which may have columns referenced in the having clause that are not referenced in the group by clause.
It all gets a bit abstract and a bit pointless really :-) but in the circumstance below we can show that a having clause can be satisfied with hashing.
create table a (a1 int, a2 char(1))
go
create table b (b1 int, b2 char(1))
go
insert a values (1, 'a')
insert a values (2, 'b')
go
insert b values (1, 'a')
insert b values (2, 'c')
go
select max(a1),a2,b2 from a,b
where a1=b1
group by a2
having a2=b2
plan '( h_join ( sort ( t_scan [b@Gtt0] ) ) ( group_sorted ( sort ( m_join ( sort ( t_scan a ) ) ( sort ( t_scan [b@Gtt3] ) ) ) ) ) )'
The hash join at VA=9 (which will be in the showplan) is directly satisfying the having clause.
This also made me think about other more 'complex' having clauses, but I couldn't find a case where it may be directly resolved with any hash based operators, as the aggregation will move about (if the aggregate is in the having clause itself) or it will eagerly apply the having clauses ahead of the actual hash aggregation operation. It may be an odd one but it is at least one example of a having clause being resolved with hashing.
So I guess that does leave us with only order by that cannot directly be resolved with hashing, it would need some other operator in combination (I think?). I can't see a scenario whereby a hash based operator can take an unordered result set as input and give it a fixed order on output.
Cheers,
Simon