[
https://issues.apache.org/jira/browse/DRILL-4320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15135543#comment-15135543
]
Jacques Nadeau commented on DRILL-4320:
---------------------------------------
In a lot of places, we're matching too much of the plan for what we're actually
testing. I wonder if that is the case here and thus we could address my
narrowing the match profile.
> Difference in query plan on JDK8 for window function query
> ----------------------------------------------------------
>
> Key: DRILL-4320
> URL: https://issues.apache.org/jira/browse/DRILL-4320
> Project: Apache Drill
> Issue Type: Bug
> Components: Query Planning & Optimization
> Affects Versions: 1.4.0
> Environment: 4 node cluster CentOS
> Reporter: Khurram Faraaz
> Labels: JDK8SUPPORT
>
> Difference in query plan seen in window function query on JDK8 with below
> test environment, the difference being that a Project is missing after the
> initial Scan, the new plan looks more optimized. Should we update the
> expected query plan or further investigation is required ?
> Java 8
> MapR Drill 1.4.0 GA
> JDK8
> MapR FS 5.0.0 GA
> Functional/window_functions/optimization/plan/pp_03.sql
> {noformat}
> Actual plan
> 00-00 Screen
> 00-01 Project(EXPR$0=[$0])
> 00-02 Project($0=[$2])
> 00-03 Window(window#0=[window(partition {1} order by [] range
> between UNBOUNDED PRECEDING and UNBOUNDED FOLLOWING aggs [SUM($0)])])
> 00-04 SelectionVectorRemover
> 00-05 Sort(sort0=[$1], dir0=[ASC])
> 00-06 Scan(groupscan=[ParquetGroupScan
> [entries=[ReadEntryWithPath [path=maprfs:///drill/testdata/subqueries/t1]],
> selectionRoot=maprfs:/drill/testdata/subqueries/t1, numFiles=1,
> usedMetadataFile=false, columns=[`a1`, `c1`]]])
> Expected plan
> Screen
> .*Project.*
> .*Project.*
> .*Window.*range between UNBOUNDED PRECEDING and UNBOUNDED
> FOLLOWING aggs.*
> .*SelectionVectorRemover.*
> .*Sort.*
> .*Project.*
> .*Scan.*
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
