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 |
Message-ID: | 8e66f899-a264-6e90-82d0-3865178b1e18@pgmasters.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
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".
--
-David
david(at)pgmasters(dot)net
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 |