My experiences with Oracle's hash function were generally not good - there's a reason many hash algorithms exist. If/when we do hash partitioning in Postgres I'd like to see the hash function be user-definable.
+1
In my experience, hash partitioning had one use: When you had run out of ways to logically partition the data, AND you had two tables in a foreign key relationship, AND that relationship was the most common use-case for selecting the two tables. In which case, your one big join became 8 or 16 little ones, and all was well in the universe...
...until those little joins started to spill to disk, and now you need to repartition by 2x hashes, and that basically means a reload of your primary fact table, and a talk with a boss about why you painted yourself into a corner when you first did that.
Meanwhile, I think list and range are a good start. I'd prefer to see sub-partitioning before hash partitioning.
