I'm sceptical of the values being a good representative here, because from the initial data you gave us:
EXECUTIONS : 166534
BUFFER_GETS : 1633139203
DISK_READS : 1041
SQL> select 1633139203 / 166534 from dual;
1633139203/166534
-----------------
9806.6413
we're looking at around 9800 buffer gets per execution, whereas your most recent example suggests far less. It may well be the case the *some* special values are causing a much high buffer get count.
So the reason this is critical is because we might opt for different strategies
1) if the buffer count is low per execution, then the plan is fine - and we probably need to alter the storage to ease contention
2) if the buffer count is actually *not* low, then the plan might need work, and hence there is a good chance the contention is due to excessive buffers per execution.
So lets look at each - but *you* will need to decide on which is more appropriate for your setup
1) If the buffer count is low, you can "spread out" the table blocks by either
a) setting a larger pctfree, or
b) perhaps hash partitioning on appropriate column
2) If the plan is poor, then from the SQL, a more sensible index looks to be potentially SYS_C0036790. So consider that a plan with that, and use a baselines/outline/etc to switch in that plan.