On Tue, Mar 14, 2017 at 10:08 AM, David Steele <da...@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 -- Sent via pgsql-hackers mailing list (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers