[ https://issues.apache.org/jira/browse/KUDU-2300?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16366013#comment-16366013 ]
Grant Henke commented on KUDU-2300: ----------------------------------- I think that Kudu internally can optimize it's ranges into slightly different ranges but still correct ranges. For example kudu might increment by the smallest unit and convert < to <=. I agree this could be confusing because it doesn't match exactly the same syntax as when created, but it is in fact the same logic. I need to look deeper to validate that is in-fact what is happening. In your example what values/command did you use to create the range partition? > Partition schema doesn't show correct type of bounds for range partitions > ------------------------------------------------------------------------- > > Key: KUDU-2300 > URL: https://issues.apache.org/jira/browse/KUDU-2300 > Project: Kudu > Issue Type: Bug > Components: master > Affects Versions: 1.5.0 > Reporter: Andre Araujo > Priority: Major > > The Partition Schema section of the master Web UI always show the range > partition with an {{EXCLUSIVE}} upper bound and an {{INCLUSIVE}} lower > bounce, regardless of what the actual bounds' types are. > For example, the partition below was created with two {{INCLUSIVE}} bounds, > but the upper bound is shown incorrectly: > {code:java} > HASH (CALLING_NUMBER_INT, CALLED_NUMBER_INT) PARTITIONS 2, > RANGE (PERIOD_START_TIME) ( > PARTITION 2018-02-15T00:00:00.000001Z <= VALUES < > 2018-02-16T00:00:00.000000Z > ){code} -- This message was sent by Atlassian JIRA (v7.6.3#76005)