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

  1. Refactor get_partition_for_tuple a bit.

  2. Adopt Bob Jenkins' improved hash function for hash_any(). This changes the

  3. Improve hash_any() to use word-wide fetches when hashing suitably aligned