On Thu, Aug 3, 2017 at 5:50 PM, Andres Freund <and...@anarazel.de> wrote: > On 2017-08-03 17:43:44 -0400, Robert Haas wrote: >> For me, the basic point here is that we need a set of hash functions >> for hash partitioning that are different than what we use for hash >> indexes and hash joins -- otherwise when we hash partition a table and >> create hash indexes on each partition, those indexes will have nasty >> clustering. Partitionwise hash joins will have similar problems. So, >> a new set of hash functions specifically for hash partitioning is >> quite desirable. > > Couldn't that just as well solved by being a bit smarter with an IV? I > doubt we want to end up with different hashfunctions for sharding, > partitioning, hashjoins (which seems to form a hierarchy). Having a > working hash-combine function, or even better a hash API that can > continue to use the hash's internal state, seems a more scalable > solution.
That's another way to go, but it requires inventing a way to thread the IV through the hash opclass interface. That's actually sort of a problem anyway. Maybe I ought to have started with the question of how we're going to make that end of things work. We could: - Invent a new hash_partition AM that doesn't really make indexes but supplies hash functions for hash partitioning. - Add a new, optional support function 2 to the hash AM that takes a value of the type *and* an IV as an argument. - Something else. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
