Can you please do an explain plan over the two aggregate queries. That way
we can know where most of the time is being spent, is it in the query
planning phase or is it query execution that is taking longer. Please share
the query plans and the time taken for those explain plan statements.
On Mon,
Please find the query plan for both queries. FYI: I am not seeing
any planning difference between these 2 queries except Cost.
/ Query on GZ
/
0: jdbc:drill:> explain plan for select channelid, count(serverTime) from
dfs.`/t
Github user daveoshinsky commented on the issue:
https://github.com/apache/drill/pull/517
Thanks Jinfeng for the very clear explanation, and pointer to
ExpressionTreeMaterializer.java. Â Rather than change
ExpressionTreeMaterializer.java, with which I am completely unfamiliar, I added
Jinfeng,
Please see my new commit & comment in PR 517.
I attached debugger to Drill and found it's passing through line 172 (not
315-316) of ExpressionTreeMaterializer.java, and that the "toType" object is
one of those runtime generated ones (name like TypeProtos$MajorType@8570).
Rather than a
Github user jinfengni commented on the issue:
https://github.com/apache/drill/pull/517
> I attached debugger to Drill and found it's passing through line 172 (not
315-316) of ExpressionTreeMaterializer.java, and that the "toType" object is
one of those runtime generated ones (name lik
Github user daveoshinsky commented on the issue:
https://github.com/apache/drill/pull/517
No, negative precision will not work properly. Â I committed another change
to PR-517 to handle this.
Quite honestly, I do not know how to fix the problem as you suggest in
ExpressionTreeMate
Parth Chandra created DRILL-4826:
Summary: Query against INFORMATION_SCHEMA.TABLES degrades as the
number of views increases
Key: DRILL-4826
URL: https://issues.apache.org/jira/browse/DRILL-4826
Proje
Dechang Gu created DRILL-4827:
-
Summary: Checking modification time of directories takes too long,
needs to be improved
Key: DRILL-4827
URL: https://issues.apache.org/jira/browse/DRILL-4827
Project: Apach
Rahul Challapalli created DRILL-4828:
Summary: We are not reading from sub-directory cache when we have
a filter on an auto-partition column
Key: DRILL-4828
URL: https://issues.apache.org/jira/browse/DRILL-482
+1
The report looks good.
Just curious: the dev and issues lists show about a 40% drop off compared to
last quarter. Any idea why?
Julian
> On Aug 3, 2016, at 11:20 PM, Parth Chandra wrote:
>
> Below is the proposed report for the August board meeting. Please provide
> any comments/corre
I think the drop off is partly due to a bunch of developers focussing more
on their day jobs and/or summer vacations. I'd expect the numbers to pick
up next quarter.
On Thu, Aug 4, 2016 at 3:54 PM, Julian Hyde wrote:
> +1
>
> The report looks good.
>
> Just curious: the dev and issues lists show
Hi Subbu,
Yes we can discuss this on the next hangout. If Jason is able to attend
we can discuss some way to address his concern.
Parth
On Wed, Aug 3, 2016 at 10:24 AM, Subbu Srinivasan
wrote:
> Hi Folks,
> When can we discuss this feature? Would next hangout be appropriate?
>
> Thanks
> Sub
Github user paul-rogers commented on the issue:
https://github.com/apache/drill/pull/517
The proximate cause of this particular issue is the mechanism by which the
cast function is being generated. As others have noted, the code is passing
through lines 316-316. My guess is that the m
Github user paul-rogers commented on the issue:
https://github.com/apache/drill/pull/517
The plot thickens. I tried the fix of setting the precision to a constant
of 10. This uncovered a larger issue. The template in question generates cast
functions for (INTEGER, BIGINT) x (DECIMAL9,
Github user daveoshinsky commented on the issue:
https://github.com/apache/drill/pull/517
Thanks for looking at this, Paul. Â If there are problems with comparing an
input decimal (from the "where clause", for example) against the data, it is
because of the algorithms for comparing de
GitHub user jinfengni opened a pull request:
https://github.com/apache/drill/pull/559
DRILL-4825: Fix incorrect result issue caused by partition pruning whâ¦
â¦en same tables are queried multiple times with different filters in
query.
1) Introduce DirPrunedEnumerableTable
Github user jinfengni commented on the issue:
https://github.com/apache/drill/pull/559
@amansinha100 , could you please review this patch?
Unit test / functional regression have passed.
---
If your project is set up for it, you can reply to this email and have your
reply ap
Ok so query planning took less than one second in both the aggregate
queries.
Looks like most of the time is getting spent in query execution.
On Thu, Aug 4, 2016 at 5:13 PM, Shankar Mane
wrote:
> Please find the query plan for both queries. FYI: I am not seeing
> any planning difference between
Github user amansinha100 commented on a diff in the pull request:
https://github.com/apache/drill/pull/559#discussion_r73649124
--- Diff:
exec/java-exec/src/main/java/org/apache/drill/exec/planner/logical/DirPrunedEnumerableTableScan.java
---
@@ -0,0 +1,73 @@
+/**
+ * Lice
Github user amansinha100 commented on a diff in the pull request:
https://github.com/apache/drill/pull/559#discussion_r73649293
--- Diff:
exec/java-exec/src/test/java/org/apache/drill/TestPartitionFilter.java ---
@@ -386,4 +386,49 @@ public void testPartitionFilterWithInSubquery()
Github user amansinha100 commented on a diff in the pull request:
https://github.com/apache/drill/pull/559#discussion_r73649304
--- Diff:
exec/java-exec/src/test/java/org/apache/drill/TestPartitionFilter.java ---
@@ -386,4 +386,49 @@ public void testPartitionFilterWithInSubquery()
Github user amansinha100 commented on a diff in the pull request:
https://github.com/apache/drill/pull/559#discussion_r73649603
--- Diff:
exec/java-exec/src/main/java/org/apache/drill/exec/store/dfs/FileSelection.java
---
@@ -402,4 +402,18 @@ public String getCacheFileRoot() {
22 matches
Mail list logo
