Uh oh!
There was an error while loading. Please reload this page.
[SPARK-26191][SQL] Control truncation of Spark plans via maxFields parameter - #23159
[SPARK-26191][SQL] Control truncation of Spark plans via maxFields parameter#23159MaxGekk wants to merge 9 commits into
Conversation
MaxGekk
commented
Nov 27, 2018
ping @hvanhovell |
SparkQA
commented
Nov 28, 2018
Test build #99342 has finished for PR 23159 at commit
|
MaxGekk
commented
Nov 28, 2018
@gatorsmile@cloud-fan Could you look at the changes - extracted from another PR: #22429 |
SparkQA
commented
Nov 30, 2018
Test build #99513 has finished for PR 23159 at commit
|
SparkQA
commented
Nov 30, 2018
Test build #99520 has finished for PR 23159 at commit
|
MaxGekk
commented
Nov 30, 2018
jenkins, retest this, please |
SparkQA
commented
Dec 1, 2018
Test build #99527 has finished for PR 23159 at commit
|
MaxGekk
commented
Dec 4, 2018
@HyukjinKwon@dongjoon-hyun@srowen@zsxwing Do you have any objections of this PR? |
srowen
commented
Dec 4, 2018
Rather than change every single call to this method, if this should generally be the value of the argument, then why not make it the default value or something? |
SparkQA
commented
Dec 4, 2018
Test build #99678 has finished for PR 23159 at commit
|
MaxGekk
commented
Dec 4, 2018
New parameter aims to solve the problem when there are multiple callers, and each of them needs different maximum fields. So, a feasible approach is to propagate |
srowen
left a comment
There was a problem hiding this comment.
Ah OK so not every call would just pass the value SQLConf.get.maxToStringFields? It looked like it from the code here but I didn't examine the whole diff. If it were really always SQLConf.get.maxToStringFields and configured that way this could be simpler, but I suppose it isn't.
| case p if p.expressions.exists(hasGenerator) => | ||
| throw new AnalysisException("Generators are not supported outside the SELECT clause, but " + | ||
| "got: " + p.simpleString) | ||
| "got: " + p.simpleString((SQLConf.get.maxToStringFields))) |
SparkQA
commented
Dec 5, 2018
Test build #99715 has finished for PR 23159 at commit
|
MaxGekk
commented
Dec 5, 2018
jenkins, retest this, please |
SparkQA
commented
Dec 5, 2018
Test build #99735 has finished for PR 23159 at commit
|
dongjoon-hyun
commented
Dec 6, 2018
cc @cloud-fan and @gatorsmile . |
HyukjinKwon
commented
Dec 11, 2018
Looks okay but let me leave it to @cloud-fan, @gatorsmile and @hvanhovell |
MaxGekk
commented
Dec 11, 2018
@hvanhovell We all are waiting for your decision ;-). Please, review the PR. |
SparkQA
commented
Dec 21, 2018
Test build #100349 has finished for PR 23159 at commit
|
MaxGekk
commented
Dec 22, 2018
I am going to close the PR since nobody interested in it :-( |
hvanhovell
commented
Dec 24, 2018
@MaxGekk can you resolve the merge conflicts? |
hvanhovell
commented
Dec 24, 2018
LGTM |
SparkQA
commented
Dec 24, 2018
Test build #100425 has finished for PR 23159 at commit
|
hvanhovell
commented
Dec 27, 2018
merging to master. |
…rameter ## What changes were proposed in this pull request? In the PR, I propose to add `maxFields` parameter to all functions involved in creation of textual representation of spark plans such as `simpleString` and `verboseString`. New parameter restricts number of fields converted to truncated strings. Any elements beyond the limit will be dropped and replaced by a `"... N more fields"` placeholder. The threshold is bumped up to `Int.MaxValue` for `toFile()`. ## How was this patch tested? Added a test to `QueryExecutionSuite` which checks `maxFields` impacts on number of truncated fields in `LocalRelation`. Closesapache#23159 from MaxGekk/to-file-max-fields. Lead-authored-by: Maxim Gekk <max.gekk@gmail.com> Co-authored-by: Maxim Gekk <maxim.gekk@databricks.com> Signed-off-by: Herman van Hovell <hvanhovell@databricks.com>
…rameter ## What changes were proposed in this pull request? In the PR, I propose to add `maxFields` parameter to all functions involved in creation of textual representation of spark plans such as `simpleString` and `verboseString`. New parameter restricts number of fields converted to truncated strings. Any elements beyond the limit will be dropped and replaced by a `"... N more fields"` placeholder. The threshold is bumped up to `Int.MaxValue` for `toFile()`. ## How was this patch tested? Added a test to `QueryExecutionSuite` which checks `maxFields` impacts on number of truncated fields in `LocalRelation`. Closesapache#23159 from MaxGekk/to-file-max-fields. Lead-authored-by: Maxim Gekk <max.gekk@gmail.com> Co-authored-by: Maxim Gekk <maxim.gekk@databricks.com> Signed-off-by: Herman van Hovell <hvanhovell@databricks.com>
What changes were proposed in this pull request?
In the PR, I propose to add
maxFieldsparameter to all functions involved in creation of textual representation of spark plans such assimpleStringandverboseString. New parameter restricts number of fields converted to truncated strings. Any elements beyond the limit will be dropped and replaced by a"... N more fields"placeholder. The threshold is bumped up toInt.MaxValuefortoFile().How was this patch tested?
Added a test to
QueryExecutionSuitewhich checksmaxFieldsimpacts on number of truncated fields inLocalRelation.