On Tue, Mar 14, 2017 at 10:08 AM, David Steele <david@pgmasters.net> wrote:
> This patch is marked as POC and after a read-through I agree that's
> exactly what it is.
Just out of curiosity, were you looking at Nagata-san's patch, or Amul's?
> 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".
Regrettably, I do think it's too late to squeeze hash partitioning
into v10, but I plan to try to get something committed for v11. I was
heavily involved in the design of Amul's patch, and I think that
design solves several problems that would be an issue for us if we did
as Nagata-san is proposing. For example, he proposed this:
CREATE TABLE h1 PARTITION OF h;CREATE TABLE h2 PARTITION OF h;CREATE TABLE h3 PARTITION OF h;
That looks OK if you are thinking of typing this in interactively, but
if you're doing a pg_dump, maybe with --binary-upgrade, you don't want
the meaning of a series of nearly-identical SQL commands to depend on
the dump ordering. You want it to be explicit in the SQL command
which partition is which, and Amul's patch solves that problem. Also,
Nagata-san's proposal doesn't provide any way to increase the number
of partitions later, and Amul's approach gives you some options there.
I'm not sure those options are as good as we'd like them to be, and if
not then we may need to revise the approach, but I'm pretty sure
having no strategy at all for changing the partition count is not good
enough.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
