On Tue, 14 Mar 2017 10:08:14 -0400 David Steele <da...@pgmasters.net> wrote:
> 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". I am sorry for my late response. I had not a enough time because I had a business trip and was busy for other works. I agree that fixing the number of partitions is bad and a way to increase or decrease partitions should be provided. I also think using linear hashing would be good as Amul is mentioning, but I have not implemented it in my patch yet. I also understanded that my design has a problem during pg_dump and pg_upgrade, and that some information to identify the partition is required not depending the command order. However, I feel that Amul's design is a bit complicated with the rule to specify modulus. I think we can use simpler syntax, for example, as below. CREATE TABLE h1 PARTITION OF h FOR (0); CREATE TABLE h2 PARTITION OF h FOR (1); CREATE TABLE h3 PARTITION OF h FOR (2); If user want to user any complicated partitioning rule, it can be defined by specifying a user-defined hash function at creating partitioned table. If the hash function is omitted, we will be able to use default hash operator class as well as in Amul's patch. Attached is the updated patch taking the comments from Aleksander and Rushabh. HASH keyword and unnecessary spaces are removed, and some comments are added. Thanks, -- Yugo Nagata <nag...@sraoss.co.jp>
hash_partition.patch.v2
Description: Binary data
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
