Re: [POC] hash partitioning
David Steele <david@pgmasters.net>
From: David Steele <david@pgmasters.net>
To: Yugo Nagata <nagata@sraoss.co.jp>
Cc: amul sul <sulamul@gmail.com>, Greg Stark <stark@mit.edu>,
PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2017-03-14T14:08:14Z
Lists: pgsql-hackers
On 3/3/17 8:33 AM, amul sul wrote: > On Fri, Mar 3, 2017 at 5:00 PM, Greg Stark <stark@mit.edu > > It also has the advantage that it's easier to see how to add more > partitions. You just split all the ranges and (and migrate the > data...). There's even the possibility of having uneven partitions if > you have a data distribution skew -- which can happen even if you have > a good hash function. In a degenerate case you could have a partition > for a single hash of a particularly common value then a reasonable > number of partitions for the remaining hash ranges. > > Initially > we > had > to have > somewhat similar thought to make a range of hash > values for > > each partition, using the same half-open interval syntax we use in general: > <...> > So it's pretty > > user-unfriendly. This patch is marked as POC and after a read-through I agree that's exactly what it is. As such, I'm not sure it belongs in the last commitfest. Furthermore, there has not been any activity or a new patch in a while and we are halfway through the CF. Please post an explanation for the delay and a schedule for the new patch. If no patch or explanation is posted by 2017-03-17 AoE I will mark this submission "Returned with Feedback". -- -David david@pgmasters.net
Commits
-
Refactor get_partition_for_tuple a bit.
- f0a0c17c1b12 11.0 landed
-
Adopt Bob Jenkins' improved hash function for hash_any(). This changes the
- 8205258fa675 8.4.0 cited
-
Improve hash_any() to use word-wide fetches when hashing suitably aligned
- 2604359251d3 8.4.0 cited