With hash partitioning you are not expected, in general, to end up with a small number of partitions being accessed more heavily than the rest. So your indexes will also not fit into memory.
I have the feeling that using a hash function to distribute rows simply contradicts the basic assumption of when you would think of partitioning your table at all: that is to make sure the most active part of the table and indexes is small enough to be cached in memory.
While hash partitioning doesn't appeal to me, I think this may be overly pessimistic. It would not be all that unusual for your customers to take turns being highly active and less active. Especially if you do occasional bulk loads all with the same customer_id for any given load, for example. So while you might not have a permanently hot partition, you could have partitions which are hot in turn. Of course you could get the same benefit (and probably better) with list or range partitioning rather than hash, but then you have to maintain those lists or ranges when you add new customers.
