Re: [POC] hash partitioning

From: David Steele <david(at)pgmasters(dot)net>
To: Yugo Nagata <nagata(at)sraoss(dot)co(dot)jp>
Cc: amul sul <sulamul(at)gmail(dot)com>, Greg Stark <stark(at)mit(dot)edu>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [POC] hash partitioning
Date: 2017-03-14 14:08:14
Views: Raw Message | Whole Thread | Download mbox | Resend email
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(at)mit(dot)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".


In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message David Steele 2017-03-14 14:18:47 Re: Patch: Optimize memory allocation in function 'bringetbitmap'
Previous Message Tom Lane 2017-03-14 13:56:33 Re: Gather Merge