It was only a trivial bit of code I whipped up in about fiften minutes to make the point that it was possible for either aggregation to be the faster depending on things like level of aggregation – it wasn’t anything designed to investigate the phenomenon in any depth:

create table t1 nologging
as
with generator as (
	select	--+ materialize
		rownum 	id
	from	all_objects 
	where	rownum <= 3000
)
select
	lpad(mod(rownum,1000),6)	small_vc_K,
	lpad(rownum,6)			small_vc_M
	from
	generator	v1,
	generator	v2
where
	rownum <= 1000000
;


begin
	dbms_stats.gather_table_stats(
		ownname		 => user,
		tabname		 =>'T1',
		estimate_percent => null,
		block_sample 	 => true,
		method_opt 	 => 'for all columns size 1'
	);
end;
/


set serveroutput off
set timing on

spool hash_agg

prompt	===========================
prompt	1000 distinct values (hash)
prompt	===========================

select
	/*+ gather_plan_statistics 1000 */
	count(*)
from
	(
	select	/*+ no_merge */
		distinct small_vc_K
	from
		t1
	)
;

select * from table(dbms_xplan.display_cursor(null,null,'allstats last'));

prompt	===========================
prompt	1000 distinct values (sort)
prompt	===========================

select
	/*+ gather_plan_statistics 1000 */
	count(*)
from
	(
	select	/*+ no_merge no_use_hash_aggregation */
		distinct small_vc_K
	from
		t1
	)
;

select * from table(dbms_xplan.display_cursor(null,null,'allstats last'));


prompt	==============================
prompt	1000000 distinct values (hash)
prompt	==============================

select
	/*+ gather_plan_statistics 1000000 */
	count(*)
from
	(
	select	/*+ no_merge */
		distinct small_vc_M
	from
		t1
	)
;

select * from table(dbms_xplan.display_cursor(null,null,'allstats last'));

prompt	==============================
prompt	1000000 distinct values (sort)
prompt	==============================

select
	/*+ gather_plan_statistics 1000000 */
	count(*)
from
	(
	select	/*+ no_merge no_use_hash_aggregation */
		distinct small_vc_M
	from
		t1
	)
;

select * from table(dbms_xplan.display_cursor(null,null,'allstats last'));

A few months ago, I had a similar issue. A job that was processing data by Monthly Partitions had been tested against year 2010 partitions and performed well in Production as it began processing 2010 partitions. However, as it went “back in time” to the year 2009, it suddenly took excruciatingly long from November 2009. The Group By was overflowing to disk — with tempspace usage more than 3x the actual data volume. I found that data had been updated back in December 2009 and the average row length had changed. So, I suspected that the Hash Group By was performing poorly against the older data because of the “nature of the data”. However, I never did get a chance to prove my suspicion — viz by disabling groupbyhashaggregation and testing each month individually.
(A different process was implemented so that code was scrapped).

If you can publish the way you generated the two datasets, I can run more tests.

Hemant K Chitale

That’s a nice way of summarising the difference.
We might also add that the sort aggregation is sensitive to the pre-existing order of the data in a way that the hash aggregation is not. (Which reminds me of the answer to a quiz about sorting I set some time ago.)

I’ve just created two data sets and run a ‘select distinct’ against them. The first data set was designed to aggregate down from a large volume to a small volume – the hash aggregation was 30% faster than the sort aggregation. The second data set aggregated a large data set without reducing the size very much – the sort aggregation was about 30% faster than the hash aggregation.

The memory requirement for the hash aggregation was much larger than for the sort aggregates, and the temp space used for the hash aggregation was larger then for the sort aggregation when I made it spill to disc.

I haven’t looked at the hash aggregation closely, but I think it is trying to reduce CPU usage by using more memory than the sort. However, when there is little aggregation taking place the CPU cost of larger memory allocations exceeds the CPU saving of not sorting. Moreover, on the dump to disc the sort aggregate simply has to store streams of sorted data which the hash aggregation probably has to store the data and a significant amount of hashing structure (possibly hash keys) – which means that hash aggregations that spill to disk would suffer an I/O disadvantage.

I think someone made a comment on one of my other postings that the variable (_smm_max_size) setting the maximum memory for a single workarea operation was a 32 bit integer: which means the maximum memory you could use for a (serial) hash aggregation would be 4GB irrepespective of the available PGA. (It might even be 2GB if it’s a signed 32-bit).

Thanks.

I did open an SR some time ago to enquire about plans to include this information at some point and was told that it wasn’t going to happen – seems like a big hole of missing potentially valuable information to me.