Re: Declarative partitioning - another take
Amit Langote <langote_amit_f8@lab.ntt.co.jp>
On 2016/09/08 21:38, Rajkumar Raghuwanshi wrote:
> On Wed, Sep 7, 2016 at 3:58 PM, Amit Langote wrote:
>> On 2016/09/07 17:56, Rajkumar Raghuwanshi wrote:
>>>
>>> In this case not sure how to create partition table. Do we have something
>>> like we have UNBOUNDED for range partition or oracle have "DEFAULT" for
>>> list partition.
>>>
>>> create table employee (empid int, dept varchar) partition by list(dept);
>>> create table emp_p1 partition of employee for values in ('IT');
>>> create table emp_p2 partition of employee for values in ('HR');
>>> create table emp_p3 partition of employee for values in (??);
>>
>> Sorry, no such feature is currently offered. It might be possible to
>> offer something like a "default" list partition which accepts values other
>> than those specified for other existing partitions. However, that means
>> if we add a non-default list partition after a default one has been
>> created, the implementation must make sure that it moves any values from
>> the default partition that now belong to the newly created partition.
>
> Thanks for clarifying, But I could see same problem of moving data when
> adding a new non-default partition with unbounded range partition.
>
> For example give here, Initially I have create a partition table test with
> test_p3 as unbounded end,
> Later tried to change test_p3 to contain 7-9 values only, and adding a new
> partition test_p4 contain 10-unbound.
>
> --create partition table and some leafs
> CREATE TABLE test (a int, b int) PARTITION BY RANGE(a);
> CREATE TABLE test_p1 PARTITION OF test FOR VALUES START (1) END (4);
> CREATE TABLE test_p2 PARTITION OF test FOR VALUES START (4) END (7);
> CREATE TABLE test_p3 PARTITION OF test FOR VALUES START (7) END UNBOUNDED;
>
> --insert some data
> INSERT INTO test SELECT i, i*10 FROM generate_series(1,3) i;
> INSERT INTO test SELECT i, i*10 FROM generate_series(4,6) i;
> INSERT INTO test SELECT i, i*10 FROM generate_series(7,13) i;
>
> --directly not able to attach test_p4 because of overlap error, hence
> detached test_p3 and than attaching test_p4
> SELECT tableoid::regclass,* FROM test;
> tableoid | a | b
> ----------+----+-----
> test_p1 | 1 | 10
> test_p1 | 2 | 20
> test_p1 | 3 | 30
> test_p2 | 4 | 40
> test_p2 | 5 | 50
> test_p2 | 6 | 60
> test_p3 | 7 | 70
> test_p3 | 8 | 80
> test_p3 | 9 | 90
> test_p3 | 10 | 100
> test_p3 | 11 | 110
> test_p3 | 12 | 120
> test_p3 | 13 | 130
> (13 rows)
>
> ALTER TABLE test DETACH PARTITION test_p3;
> CREATE TABLE test_p4 (like test);
> ALTER TABLE test ATTACH PARTITION test_p4 FOR VALUES start (10) end
> UNBOUNDED;
>
> --now can not attach test_p3 because of overlap with test_p4, causing data
> loss from main test table.
> ALTER TABLE test ATTACH PARTITION test_p3 FOR VALUES start (7) end (10);
> ERROR: source table contains a row violating partition bound specification
> ALTER TABLE test ATTACH PARTITION test_p3 FOR VALUES start (7) end (13);
> ERROR: partition "test_p3" would overlap partition "test_p4"
In this particular case, you will have to move any rows in test_p3 with
key > or >= 10 into the new partition test_p4 using dml (to not lose any
data). Then attach test_p3 as partition for values start (7) end (10);
you won't get either of the above errors.
Looking forward, what we need I think is a split partition command.
Adding a new partition that overlaps the default list partition or
unbounded range partition could be done by splitting the latter. Perhaps
something like:
alter table test
split partition test_p3 at (10) [inclusive | exclusive] with test_p4;
The above command would make test_p3 into 2 partitions:
test_p3 start (7) end (10) [inclusive | exclusive]
test_p4 start (10) [exclusive | inclusive] end unbounded
Any rows in test_p3 with key > or >= 10 will be moved into the newly
created test_p4 as part of the execution of this command.
For your list partitioning example:
create table employee (empid int, dept varchar) partition by list(dept);
create table emp_p1 partition of employee for values in ('IT');
create table emp_p2 partition of employee for values in ('HR');
create table emp_p3 partition of employee for values in (default);
alter table emp
split partition emp_p3 with emp_p3 ('ACCT') emp_p4 (default);
Any rows in emp_p3 with key != 'ACCT' will be moved into the newly created
default partition emp_p4.
But for time being, I think we could provide the syntax and mechanism for
default list partition seeing as we have the same for range partitioned
table (namely a range partition with unbounded start or end). Although
with the limitations as discussed.
Thoughts?
Thanks,
Amit
Commits
-
Fix typo.
- 03bf59676ea0 10.0 landed
-
Document trigger-firing behavior for inheritance/partitioning.
- e17628145ac3 10.0 landed
-
Fire per-statement triggers on partitioned tables.
- e180c8aa8caf 10.0 landed
-
Set ecxt_scantuple correctly for tuple routing.
- 132488bfee68 10.0 landed
-
Fix interaction of partitioned tables with BulkInsertState.
- b1ecb9b3fcfb 10.0 landed
-
Avoid core dump for empty prepared statement in an aborted transaction.
- ba61a04bc7fe 10.0 cited
-
Fix some problems in check_new_partition_bound().
- 8a8afe2f54c2 10.0 landed
-
Remove unnecessary arguments from partitioning functions.
- 18fc5192a631 10.0 cited
-
Fix reporting of constraint violations for table partitioning.
- f1b4c771ea74 10.0 cited
-
Fix tuple routing in cases where tuple descriptors don't match.
- 2ac3ef7a01df 10.0 cited
-
Invalid parent's relcache after CREATE TABLE .. PARTITION OF.
- 7cd0fd655d68 10.0 landed
-
Doc: improve documentation about inheritance.
- 162477a63d3c 10.0 cited