kudu-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dan Burkert <danburk...@apache.org>
Subject Re: mixing range and hash partitioning
Date Sat, 25 Feb 2017 00:09:41 GMT
Hi Paul,

I can't reproduce the behavior you are describing, I always get a single
unbounded range partition when creating the table without specifying range
bounds or splits (regardless of hash partitioning). I searched and couldn't
find a unit test for this behavior, so I wrote one - you might compare your
code against my test. https://gerrit.cloudera.org/#/c/6153/

Thanks,
Dan

On Fri, Feb 24, 2017 at 2:41 PM, Paul Brannan <paul.brannan@thesystech.com>
wrote:

> I can verify that dropping the unbounded range partition allows me to
> later add bounded partitions.
>
> If I only have range partitioning (by commenting out the call to
> add_hash_partitions), adding a bounded partition succeeds, regardless of
> whether I first drop the unbounded partition.  This seems surprising; why
> the difference?
>
> On Fri, Feb 24, 2017 at 4:20 PM, Dan Burkert <danburkert@apache.org>
> wrote:
>
>> Hi Paul,
>>
>> I think the issue you are running into is that if you don't add a range
>> partition explicitly during table creation (by calling add_range_partition
>> or inserting a split with add_range_partition_split), Kudu will default to
>> creating 1 unbounded range partition.  So your two options are to add the
>> range partition during table creation time, or if you only know that
>> partition you want at a later time, you can drop the existing partition
>> (alterer->DropRangePartition with two empty rows), then add the range
>> partition.  Note that dropping the range partition will effectively
>> truncate the table.  This can be done with the same alterer in a single
>> transaction.  If you want to see a bunch of examples, you can check out
>> this unit test: https://github.com/apache/kudu/blob/master/src/kudu/
>> integration-tests/alter_table-test.cc#L1106.
>>
>> - Dan
>>
>> On Fri, Feb 24, 2017 at 10:53 AM, Paul Brannan <
>> paul.brannan@thesystech.com> wrote:
>>
>>> I'm trying to create a table with one-column range-partitioned and
>>> another column hash-partitioned.  Documentation for add_hash_partitions and
>>> set_range_partition_columns suggest this should be possible ("Tables must
>>> be created with either range, hash, or range and hash partitioning").
>>>
>>> I have a schema with three INT64 columns ("time", "key", and "value").
>>> When I create the table, I set up the partitioning:
>>>
>>> (*table_creator)
>>>   .table_name("test_table")
>>>   .schema(&schema)
>>>   .add_hash_partitions({"key"}, 2)
>>>   .set_range_partition_columns({"time"})
>>>   .num_replicas(1)
>>>   .Create()
>>>
>>> I later try to add a partition:
>>>
>>> auto timesplit(KuduSchema & schema, std::int64_t t) {
>>>   auto split = schema.NewRow();
>>>   check_ok(split->SetInt64("time", t));
>>>   return split;
>>> }
>>>
>>> alterer->AddRangePartition(
>>>   timesplit(schema, date_start),
>>>   timesplit(schema, next_date_start));
>>>
>>> check_ok(alterer->Alter());
>>>
>>> But I get an error "Invalid argument: New range partition conflicts with
>>> existing range partition".
>>>
>>> How are hash and range partitioning intended to be mixed?
>>>
>>>
>>
>

Mime
View raw message