kudu git commit: [docs] - Impala Hash Partition Example Correction

[mp...@apache.org]

Repository: kudu
Updated Branches:
  refs/heads/master e0c6ced3e -> 6d696bcf7


[docs] - Impala Hash Partition Example Correction

The Impala doc has a basic hash partitioning examples
and incorrectly explains the hash partition that is
created. This fix corrects that.

Change-Id: I4039f6326602fe854a090dc16cf65b5807d4617f
Reviewed-on: http://gerrit.cloudera.org:8080/4615
Reviewed-by: Mike Percy <mp...@apache.org>
Tested-by: Mike Percy <mp...@apache.org>


Project: http://git-wip-us.apache.org/repos/asf/kudu/repo
Commit: http://git-wip-us.apache.org/repos/asf/kudu/commit/6d696bcf
Tree: http://git-wip-us.apache.org/repos/asf/kudu/tree/6d696bcf
Diff: http://git-wip-us.apache.org/repos/asf/kudu/diff/6d696bcf

Branch: refs/heads/master
Commit: 6d696bcf7522fb5dfbc3188fe01b3d0ddbd03df6
Parents: e0c6ced
Author: Jordan Birdsell <jo...@gmail.com>
Authored: Tue Oct 4 06:47:20 2016 -0400
Committer: Mike Percy <mp...@apache.org>
Committed: Tue Oct 4 12:51:08 2016 +0000

----------------------------------------------------------------------
 docs/kudu_impala_integration.adoc | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
----------------------------------------------------------------------


http://git-wip-us.apache.org/repos/asf/kudu/blob/6d696bcf/docs/kudu_impala_integration.adoc
----------------------------------------------------------------------
diff --git a/docs/kudu_impala_integration.adoc b/docs/kudu_impala_integration.adoc
index 971761c..d602d4b 100755
--- a/docs/kudu_impala_integration.adoc
+++ b/docs/kudu_impala_integration.adoc
@@ -651,7 +651,7 @@ Hash partitioning is a reasonable approach if primary key values are evenly
 distributed in their domain and no data skew is apparent, such as timestamps or
 serial IDs.
 
-The following example creates 16 tablets by hashing the `id` column. This spreads
+The following example creates 16 tablets by hashing the `id` and `sku` columns. This spreads
 writes across all 16 tablets. In this example, a query for a range of `sku` values
 is likely to need to read all 16 tablets, so this may not be the optimum schema for
 this table. See <<advanced_partitioning>> for an extended example.