Does hash partition distribute data evenly across partitions?

Question

As per Oracle documentation, it is mentioned that hash partitioning uses oracle hashing algorithms to assign a hash value to each rows partitioning key and place it in the appropriate partition. And the data will be evenly distributed across the partitions. Ofcourse following following conditions :
1. Partition count should follow 2^n logic
2. Data in partition key column should have high cardinality.
I have used hash partitioning in some of our application tables, but data isn't distributed evenly across partitions. To verify it, i performed a small test :
Table script :
Create table ch_acct_mast_hash(
Cod_acct_no number)
Partition by hash(cod_acct_no)
PARTITIONS 128;
Data population script :
declare
i number;
l number;
begin
i := 1000000000000000;
for l in 1 .. 100000 loop
insert into ch_acct_mast_hash values (i);
i := i + 1;
end loop;
commit;
end;
Row-count check :
select count(1) from Ch_Acct_Mast_hash ; --rowcount is 100000
Gather stats script :
begin
dbms_stats.gather_table_stats('C43HDEV', 'CH_ACCT_MAST_HASH');
end;
Data distribution check :
Select min(num_rows), max(num_rows) from dba_tab_partitions
where table_name = 'CH_ACCT_MAST_HASH';
Result is :
min(num_rows) = 700
max(num_rows) = 853
As per the result, it seems there is lot of skewness in data distribution across partitions. Maybe I am missing something, or something is not right.
Can anybody help me to understand this behavior?
Edited by: Kshitij Kasliwal on Nov 2, 2012 4:49 AM

Answer 1

>
I have used hash partitioning in some of our application tables, but data isn't distributed evenly across partitions.
>
All keys with the same data value will also have the same hash value and so will be in the same partition.
So the actual hash distribution in any particular case will depend on the actual data distribution. And, as Iordan showed, the data distribution depends not only on cardinality but on the standard deviation of the key values.
To use a shorter version of that examle consider these data samples which each have 10 values. There is a calculator here
http://easycalculation.com/statistics/standard-deviation.php
0,1,0,2,0,3,0,4,0,5 - total 10, distinct 6, %distinct 60, mean 1.5, stan deviation 1.9, variance 3.6 - similar to Iordan's example
0,5,0,5,0,5,0,5,0,5 - total 10, distinct 2, %distinct 20, mean 2.5, stan dev. 2.64, variance 6.9
5,5,5,5,5,5,5,5,5,5 - total 10, distinct 1, %distinct 10, mean 5, stan dev. 0, variance 0
0,1,2,3,4,5,6,7,8,9 - total 10, distinct 10, %distinct 100, mean 4.5, stan dev. 3.03, variance 9.2
The first and last examples have the highest cardinality but only the last has unique values (i.e. 100% distinct).
Note that the first example is lower for all other attributes but that doesn't mean it would hash more evenly.
Also note that the last example, the unique values, has the highest variance.
So this is no single attribute that is controlling. As Iordan showed the first example has a high %distinct but all of those '0' values will hash to the same partition so even using a perfect hash the data would use 6 partitions.