Hash partitioning will NOT equally distribute the data among the partitioins.
 Rows of the same hash key value will go to the same partition, of course.
 Many articles describe HASH partitioning as been able to 'evenly' distribute data
 among partitions. This is really not ture. The best you can say is the data will be
 'well distributed' among the partitions. In the example here, 
 3 rows were in the first partition of the range/hash composite partitioned table. The first
 subpartition has 1 row, the 2nd 2 rows, the third partition was empty.
 
 Why not evenly distribute the rows among the partitions and disregard the key values?
     - Partition prunning would not have been possible.
 
 Do you get "partition prunning" with hash? Yes, but for equality and IN type
    queries only. Makes sense.

 Insert, delete will not cause row movemnet within hash partitioned table.
 Adding partition will. See here for an example.
 
 Drop, merge and split are not possible with hash at the moment.
 You can 'coalesce' a partition in a HASH partitioned table, however.
 See here for an example.
 
 You can exchange a hash-partitioned table with a partition in a range/hash
     composite partitioned table (9i). See here for an example.
 You can not exchange a partition in a hash partitioned table with a 
     non-partitioned table.

 The number of partitions in a hash partitioned table should be the power of 2.
 4 and 8 are subpartitions are commonly used in a range/hash composite partitioned table.