Tuning temp usage - 21GB Table

Question

Hello,
11gR2 OEL, 2 CPU machine (test box).
select id,avg(col1),avg(col2),avg(col3),avg(col4),avg(col5)
from t1
group by id;id - VARCHAR2(15) NOT NULL - Not Indexed
Avg row length - 100 bytes
Table t1 is 21GB in size. Degree 4.
The query fails with ORA-01652 even after consuming 35 GB of Temp.
Problem at hand is to reduce temp usage as DBAs are not Ok with such huge temp usage with other jobs running.
We have come up with 2 options.
1. Create Index on id column - Looks like this works but takes longer. Testing is ongoing.
2. Create Hash Partitions (10 partitions) hash by id column. Loop through each partition and compute avg.
Option 1 is being tested currently.
The question I have is, is Option 2 reliable. Is it guaranteed that a given value for id will always go to partition x ?
Meaning, is it possible the same id value is stored in more than one hash partition ?
Pls let me know.
Rgds,
Gokul

Answer 1

The table has about 270 million rows with 3 - 4 million unique ids.
Will Hash partitioning still help in this case ?With 4 million Unique IDs, you'd have to create a large number of HASH partitions to "reasonably" distribute them ! You could also use RANGE partitioning if you can predict the ID values.
But don't go and partition/re-partition a table just to suit one type of query. Partitioning can well impact all sorts of queries (and DML) against the table. So you need to review the pattern of activity, performance implications for each type of access and maintenance overheads before deciding on a partitioning scheme.
Hemant K Chitale