a) partitioning is NOT fast=true
b) you MUST understand the physics behind the data, whats happening.
Say you took a table T with columns ( ID primary key, CUST_ID, ... )
You hash partitioned into 64 partitions by ID.
You have a local index on CUST_ID.
MOST of your queries are "where cust_id = :x"
Guess what you just accomplished.
You accomplished the feat of increasing your IO by a factor of 64!!! by 64 times!!
why? well, we have 64 tiny little index segments to range scan -- your customer id could
be in any, all or none of them.
Solution -- hash partition table, range partition index by cust_id -- now you will NOT
have affected read performance at all (probably, it could be a tiny bit better with
partitioning but nothing phenomenal) but you might find that you've reduced contention on
modifications since you have N indexes and N table segments (and hence N freelists at
least and so on)
If you have my new book -- you'll laugh at how closely your example above mirrors the one
in the book, almost scary (but I only did 8 partitions, to show an 8 times increase in
IO)