Dan Burkert has posted comments on this change.
Change subject: Add docs for non-covering range partitioning
Patch Set 1:
Line 799: Starting with Kudu 0.10, Kudu supports the use of non-covering range
I don't think this feature (specifically the RANGE BOUND syntax) will be ready
in Impala for the 0.10 release. I'm not sure if we should document this in the
impala integration until its done.
Line 830: range should be added. APIs
This keyword is the specific Protobuf identifier that Kudu uses internally;
when add/drop range partition is added to impala it will hopefully look
significantly different. Perhaps say more generally an alter table [add|drop]
range partition operation.
Line 49: across tablet servers. This is most impacted by the primary key
design and the
This is only influenced by the partition schema; the primary key only
influences how data is stored/accessed within an individual tablet.
Line 53: - Only important data would be transmitted to clients, by means of
I think what this is trying to get at is that an efficient schema will be
designed such that scans will read the minimum amount of data necessary to
fulfill a query. The biggest tool here is primary key design, but partition
design also plays into it via partition pruning.
Line 147: Kudu 0.10 introduces non-covering range partitions, to mitigate some
This doesn't explain what non-covering range partitions are.
Line 165: ==== Caveats of Non-Covering Range Partitions
These caveats look like they were taken right from the design doc? I think
they are too low level, and don't really fit with the rest of this guide. They
mention some features which likely will never be implemented, and some of them
require expert-level knowledge of partitioning to understand.
I think the most important caveat when using non-covered range partitions are:
* Writes into non-covered ranges will fail with a tablet not found error.
* When adding a range partition to an existing table through an alter table
operation, the new range partition may not become visible to other existing
clients of the table until waiting for an entire 'table_locations_ttl' period,
as configured on the master (default 1 hour).
Line 288: [[column-design]]
Are there changes in here, or just a straight move?
To view, visit http://gerrit.cloudera.org:8080/3796
To unsubscribe, visit http://gerrit.cloudera.org:8080/settings
Gerrit-Owner: Misty Stanley-Jones <mi...@apache.org>
Gerrit-Reviewer: Dan Burkert <d...@cloudera.com>
Gerrit-Reviewer: Dinesh Bhat <din...@cloudera.com>
Gerrit-Reviewer: Kudu Jenkins
Gerrit-Reviewer: Todd Lipcon <t...@apache.org>