[ https://issues.apache.org/jira/browse/DRILL-4743?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15373525#comment-15373525 ]
ASF GitHub Bot commented on DRILL-4743: --------------------------------------- Github user gparai commented on a diff in the pull request: https://github.com/apache/drill/pull/534#discussion_r70505090 --- Diff: exec/java-exec/src/main/java/org/apache/drill/exec/planner/physical/PlannerSettings.java --- @@ -81,6 +83,11 @@ new RangeLongValidator("planner.identifier_max_length", 128 /* A minimum length is needed because option names are identifiers themselves */, Integer.MAX_VALUE, DEFAULT_IDENTIFIER_MAX_LENGTH); + public static final OptionValidator FILTER_MIN_SELECTIVITY_ESTIMATE_FACTOR = new MinRangeDoubleValidator("planner.filter.min_selectivity_estimate_factor", --- End diff -- This will reduce the flexibility for the user. I think we should still maintain one-on-one mappings for RelMdRowCount, RelMdSelectivity and the selectivity upper/lower bounds. Selectivity and bounds will be different e.g. for filters than for joins. > HashJoin's not fully parallelized in query plan > ----------------------------------------------- > > Key: DRILL-4743 > URL: https://issues.apache.org/jira/browse/DRILL-4743 > Project: Apache Drill > Issue Type: Bug > Affects Versions: 1.5.0 > Reporter: Gautam Kumar Parai > Assignee: Gautam Kumar Parai > Labels: doc-impacting > > The underlying problem is filter selectivity under-estimate for a query with > complicated predicates e.g. deeply nested and/or predicates. This leads to > under parallelization of the major fragment doing the join. > To really resolve this problem we need table/column statistics to correctly > estimate the selectivity. However, in the absence of statistics OR even when > existing statistics are insufficient to get a correct estimate of selectivity > this will serve as a workaround. -- This message was sent by Atlassian JIRA (v6.3.4#6332)