On Fri, Oct 28, 2016 at 3:53 AM, Amit Langote
<langote_amit...@lab.ntt.co.jp> wrote:
>> 4. I'm somewhat wondering if we ought to just legislate that the lower
>> bound is always inclusive and the upper bound is always exclusive.
>> The decision to support both inclusive and exclusive partition bounds
>> is responsible for an enormous truckload of complexity in this patch,
>> and I have a feeling it is also going to be a not-infrequent cause of
>> user error.
>
> I thought we decided at some point to go with range type like notation to
> specify range partition bound because of its flexibility. I agree though
> that with that flexibility, there will more input combinations that will
> cause error. As for the internal complexity, it's not clear to me whether
> it will be reduced by always-inclusive lower and always-exclusive upper
> bounds. We would still need to store the inclusive flag with individual
> PartitionRangeBound and consider it when comparing them with each other
> and with partition key of tuples.
We did. But I now think that was kind of silly. I mean, we also
talked about not having a hard distinction between list partitioning
and range partitioning, but you didn't implement it that way and I
think that's probably a good thing. The question is - what's the
benefit of allowing this to be configurable?
For integers, there's absolutely no difference in expressive power.
If you want to allow 1000-2000 with both bounds inclusive, you can
just say START (1000) END (2001) instead of START (1000) END (2000)
INCLUSIVE. This is also true for any other datatype where it makes
sense to talk about "the next value" and "the previous value".
Instead of making the upper bound inclusive, you can just end at the
next value instead. If you were tempted to make the lower bound
exclusive, same thing.
For strings and numeric types that are not integers, there is in
theory a loss of power. If you want a partition that allows very
value starting with 'a' plus the string 'b' but not anything after
that, you are out of luck. START ('a') END ('b') INCLUSIVE would have
done exactly what you want, but now you need to store the first string
that you *don't* want to include in that partition, and what's that?
Dunno. Or similarly if you want to store everything from 1.0 up to
and including 2.0 but nothing higher, you can't, really.
But who wants that? People who are doing prefix-based partitioning of
their text keys are going to want all of the 'a' things together, and
all of the 'b' things in another category. Same for ranges of
floating-point numbers, which are also probably an unlikely candidate
for a partitioning key anyway.
So let's look at the other side. What do we gain by excluding this
functionality? Well, we save a parser keyword: INCLUSIVE no longer
needs to be a keyword. We also can save some code in
make_one_range_bound(), RelationBuildPartitionDesc(),
copy_range_bound(), partition_rbound_cmp(), and partition_rbound_eq().
Also, if we exclude this now as I'm proposing, we can always add it
back later if it turns out that people need it. On the other hand, if
we include it in the first version, it's going to be very hard to get
rid of it if it turns out we don't want it. Once we release support
for a syntax, we're kinda stuck with it.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
