Re: [POC] hash partitioning
Dilip Kumar <dilipbalaut@gmail.com>
From: Dilip Kumar <dilipbalaut@gmail.com>
To: amul sul <sulamul@gmail.com>
Cc: Robert Haas <robertmhaas@gmail.com>,
Ashutosh Bapat <ashutosh.bapat@enterprisedb.com>, Yugo Nagata <nagata@sraoss.co.jp>, David Steele <david@pgmasters.net>,
Greg Stark <stark@mit.edu>, PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2017-06-06T08:50:53Z
Lists: pgsql-hackers
On Tue, Jun 6, 2017 at 1:03 PM, amul sul <sulamul@gmail.com> wrote: > May I ask you, how you sure about 8 is an unfit value for t1 relation? > And what if the value other than 8, for e.g. 7? Well, First I created t1 as a leaf relation like below, and I tested insert into t1 with value 8 and it was violating the partition constraint of t1, however, 7 was fine. create table t (a int) partition by hash(a); create table t1 partition of t for values with (modulus 2, remainder 1); Later I dropped this t1 and created 2 level partition with the leaf as a range. drop table t1; create table t1 partition of t for values with (modulus 2, remainder 1) partition by range(a); create table t1_1 partition of t1 for values from (8) to (10); So now, I am sure that t1_1 can accept the value 8 and its parent t1 can't. So I think this can only happen in the case of partitioned by hash that a value is legal for the child but illegal for the parent? Isn't it a good idea that if a user is inserting in the top level relation he should know for which partition exactly the constraint got violated? > > Updated patch attached. Thanks. -- Regards, Dilip Kumar EnterpriseDB: http://www.enterprisedb.com
Commits
-
Refactor get_partition_for_tuple a bit.
- f0a0c17c1b12 11.0 landed
-
Adopt Bob Jenkins' improved hash function for hash_any(). This changes the
- 8205258fa675 8.4.0 cited
-
Improve hash_any() to use word-wide fetches when hashing suitably aligned
- 2604359251d3 8.4.0 cited