Fixed a typo in the comments in RangePartitioner

[dorx]

Checked with Holden, the original author as per the log, and was told
code is right comment is wrong.

[SparkQA]

QA tests have started for PR 1473. This patch merges cleanly.
View progress: https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder/16796/consoleFull

[SparkQA]

QA results for PR 1473:
- This patch PASSES unit tests.
- This patch merges cleanly
- This patch adds no public classes

For more information see test ouptut:
https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder/16796/consoleFull

[rxin]

Actually 1000 seems a pretty large number for doing linear scan. How about 64 or 128?

[dorx]

That's why I noticed it in the first place. Would changing this number have unintended affects on people who're currently using the RangePartitioner?

[rxin]

I don't think so. If anything, it should make it faster.

[SparkQA]

QA tests have started for PR 1473. This patch merges cleanly.
View progress: https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder/16816/consoleFull

[SparkQA]

QA results for PR 1473:
- This patch FAILED unit tests.
- This patch merges cleanly
- This patch adds no public classes

For more information see test ouptut:
https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder/16816/consoleFull

[dorx]

A superficial look at the failed unit tests seems to suggest some Spark SQL optimizations rely on the fact that 1000 is set as the sequential scan threshhold. @rxin @marmbrus

[marmbrus]

It appears to me that the range partitioner is not correctly using the provided ordering in the case where it uses a binary search.

[rxin]

I filed a JIRA: https://issues.apache.org/jira/browse/SPARK-2598

[rxin]

@dorx can you close this PR? #1500 includes the change here.