On Fri, Jun 23, 2017 at 6:58 AM, Amit Langote
> On 2017/06/22 20:48, amul sul wrote:
>> While working on the another patch, I came across the case where
>> I need an auto generated partition for a mutil-column range partitioned
>> table having following range bound:
>> PARTITION p1 FROM (UNBOUNDED, UNBOUNDED) TO (10, 10)
>> PARTITION p2 FROM (10, 10) TO (10, UNBOUNDED)
>> PARTITION p3 FROM (10, UNBOUNDED) TO (20, 10)
>> PARTITION p4 FROM (20, 10) TO (20, UNBOUNDED)
>> PARTITION p5 FROM (20, UNBOUNDED) TO (UNBOUNDED, UNBOUNDED)
>> In this, a lower bound of the partition is an upper bound of the
>> previous partition.
>> While trying to create p3 partition with (10, UNBOUNDED) to (20, 10) bound,
>> got an overlap partition error.
>> Here is the SQL to reproduced this error:
>> CREATE TABLE range_parted ( i1 int, i2 int ) PARTITION BY RANGE (i1, i2);
>> CREATE TABLE p1 PARTITION OF range_parted FOR VALUES FROM (UNBOUNDED,
>> UNBOUNDED) TO (10, 10);
>> CREATE TABLE p2 PARTITION OF range_parted FOR VALUES FROM (10, 10) TO
>> (10, UNBOUNDED);
>> CREATE TABLE p3 PARTITION OF tab1 FOR VALUES FROM (10, UNBOUNDED) TO (20,
>> ERROR: partition "p3" would overlap partition "tab1_p_10_10"
>> This happened because of UNBOUNDED handling, where it is a negative infinite
>> if it is in FROM clause. Wondering can't we explicitly treat this as
>> a positive infinite value, can we?
The way we have designed our syntax, we don't have a way to tell that
p3 comes after p2 and they have no gap between those. But I don't
think that's your question. What you are struggling with is a way to
specify a lower bound (10, +infinity) so that anything with i1 > 10
would go to partition 3.
> No, we cannot. What would be greater than (or equal to) +infinite?
> Nothing. So, even if you will want p3 to accept (10, 9890148), it won't
> because 9890148 is not >= +infinite. It will accept only the rows where
> the first column is > 10 (second column is not checked in that case).
> You will have to define p3 as follows:
> CREATE TABLE p3 PARTITION OF tab1 FOR VALUES FROM (11, UNBOUNDED) TO (20, 10);
That's not exactly same as specifying (10, +infinity) in case i1 is a
float. A user can not precisely tell what would be the acceptable
value just greater than 10.
An UNBOUNDED in the lower bound is always considered as -infinity for
that data type. There is no way to specify a lower bound which has
+infinity in it. +infinite as a lower bounds for the first key may not
make sense (although that means that the partition will always be
empty), but it does make sense for keys after the first as Amul has
The question is do we have support for that and if not, will we
consider it for v10 or v11 and how.
> It's fine to use the previous partition's upper bound as the lower bound
> of the current partition, if the former does contain an UNBOUNDED value,
> because whereas a finite value divides the range into two parts (assigned
> to the two partitions respectively), an UNBOUNDED value does not. The
> latter represents an abstract end of the range (either on the positive
> side or the negative).
Not exactly for second key onwards.
The Postgres Database Company
Sent via pgsql-hackers mailing list (firstname.lastname@example.org)
To make changes to your subscription: