[
https://issues.apache.org/jira/browse/DRILL-5691?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16174352#comment-16174352
]
ASF GitHub Bot commented on DRILL-5691:
---------------------------------------
Github user amansinha100 commented on a diff in the pull request:
https://github.com/apache/drill/pull/889#discussion_r140160556
--- Diff:
exec/java-exec/src/main/java/org/apache/drill/exec/planner/cost/DrillRelMdMaxRowCount.java
---
@@ -0,0 +1,42 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+package org.apache.drill.exec.planner.cost;
+
+import org.apache.calcite.rel.core.TableScan;
+import org.apache.calcite.rel.metadata.ReflectiveRelMetadataProvider;
+import org.apache.calcite.rel.metadata.RelMdMaxRowCount;
+import org.apache.calcite.rel.metadata.RelMetadataProvider;
+import org.apache.calcite.rel.metadata.RelMetadataQuery;
+import org.apache.calcite.util.BuiltInMethod;
+import org.apache.drill.exec.planner.logical.DrillLimitRel;
+
+public class DrillRelMdMaxRowCount extends RelMdMaxRowCount {
+
+ private static final DrillRelMdMaxRowCount INSTANCE = new
DrillRelMdMaxRowCount();
+
+ public static final RelMetadataProvider SOURCE =
ReflectiveRelMetadataProvider.reflectiveSource(BuiltInMethod.MAX_ROW_COUNT.method,
INSTANCE);
+
+ public Double getMaxRowCount(DrillLimitRel rel, RelMetadataQuery mq) {
+ return rel.getRows();
+ }
+
+ @Override
+ public Double getMaxRowCount(TableScan rel, RelMetadataQuery mq) {
+ return rel.getRows();
--- End diff --
Sorry, I had been meaning to reply sooner. I think overloading the
getMaxRowCount() to return rel.getRows() can create potential issues...because
getMaxRowCount() should always return whatever is the *maximum* row count
possible for that RelNode. Here, if you return TableScan.getRows(), the value
is an *estimate*, which means in reality it could be higher. The caller might
make incorrect decision based on this value.
I am thinking about your original motivation for the changes. Are you
materializing the results into a single-row table ? It sounds like you want a
special table scan whose max row count is 1. Is materializing the only
option ? (the reason I am curious is it is odd to materialize very small data
sets such as 1 row).
> multiple count distinct query planning error at physical phase
> ---------------------------------------------------------------
>
> Key: DRILL-5691
> URL: https://issues.apache.org/jira/browse/DRILL-5691
> Project: Apache Drill
> Issue Type: Bug
> Components: Execution - Relational Operators
> Affects Versions: 1.9.0, 1.10.0
> Reporter: weijie.tong
>
> I materialized the count distinct query result in a cache , added a plugin
> rule to translate the (Aggregate、Aggregate、Project、Scan) or
> (Aggregate、Aggregate、Scan) to (Project、Scan) at the PARTITION_PRUNING phase.
> Then ,once user issue count distinct queries , it will be translated to query
> the cache to get the result.
> eg1: " select count(*),sum(a) ,count(distinct b) from t where dt=xx "
> eg2:"select count(*),sum(a) ,count(distinct b) ,count(distinct c) from t
> where dt=xxx "
> eg3:"select count(distinct b), count(distinct c) from t where dt=xxx"
> eg1 will be right and have a query result as I expected , but eg2 will be
> wrong at the physical phase.The error info is here:
> https://gist.github.com/weijietong/1b8ed12db9490bf006e8b3fe0ee52269.
> eg3 will also get the similar error.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
