[jira] [Resolved] (DRILL-3688) Drill should honor "skip.header.line.count" and "skip.footer.line.count" attributes of Hive table

[Arina Ielchiieva (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DRILL-3688?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Arina Ielchiieva resolved DRILL-3688.
-
   Resolution: Fixed
Fix Version/s: (was: Future)
   1.6.0

> Drill should honor "skip.header.line.count" and "skip.footer.line.count" 
> attributes of Hive table
> -
>
> Key: DRILL-3688
> URL: https://issues.apache.org/jira/browse/DRILL-3688
> Project: Apache Drill
>  Issue Type: Bug
>  Components: Storage - Hive
>Affects Versions: 1.1.0
> Environment: 1.1
>Reporter: Hao Zhu
>Assignee: Arina Ielchiieva
> Fix For: 1.6.0
>
>
> Currently Drill does not honor the "skip.header.line.count" attribute of Hive 
> table.
> It may cause some other format conversion issue.
> Reproduce:
> 1. Create a Hive table
> {code}
> create table h1db.testheader(col0 string)
> ROW FORMAT DELIMITED FIELDS TERMINATED BY '|'
> STORED AS TEXTFILE
> tblproperties("skip.header.line.count"="1");
> {code}
> 2. Prepare a sample data:
> {code}
> # cat test.data
> col0
> 2015-01-01
> {code}
> 3. Load sample data into Hive
> {code}
> LOAD DATA LOCAL INPATH '/xxx/test.data' OVERWRITE INTO TABLE h1db.testheader;
> {code}
> 4. Hive
> {code}
> hive> select * from h1db.testheader ;
> OK
> 2015-01-01
> Time taken: 0.254 seconds, Fetched: 1 row(s)
> {code}
> 5. Drill
> {code}
> >  select * from hive.h1db.testheader ;
> +-+
> |col0 |
> +-+
> | col0|
> | 2015-01-01  |
> +-+
> 2 rows selected (0.257 seconds)
> > select cast(col0 as date) from hive.h1db.testheader ;
> Error: SYSTEM ERROR: IllegalFieldValueException: Value 0 for monthOfYear must 
> be in the range [1,12]
> Fragment 0:0
> [Error Id: 34353702-ca27-440b-a4f4-0c9f79fc8ccd on h1.poc.com:31010]
>   (org.joda.time.IllegalFieldValueException) Value 0 for monthOfYear must be 
> in the range [1,12]
> org.joda.time.field.FieldUtils.verifyValueBounds():236
> org.joda.time.chrono.BasicChronology.getDateMidnightMillis():613
> org.joda.time.chrono.BasicChronology.getDateTimeMillis():159
> org.joda.time.chrono.AssembledChronology.getDateTimeMillis():120
> org.apache.drill.exec.expr.fn.impl.StringFunctionHelpers.memGetDate():261
> org.apache.drill.exec.expr.fn.impl.StringFunctionHelpers.getDate():218
> org.apache.drill.exec.test.generated.ProjectorGen0.doEval():67
> org.apache.drill.exec.test.generated.ProjectorGen0.projectRecords():62
> 
> org.apache.drill.exec.physical.impl.project.ProjectRecordBatch.doWork():172
> org.apache.drill.exec.record.AbstractSingleRecordBatch.innerNext():93
> 
> org.apache.drill.exec.physical.impl.project.ProjectRecordBatch.innerNext():129
> org.apache.drill.exec.record.AbstractRecordBatch.next():147
> org.apache.drill.exec.physical.impl.BaseRootExec.next():83
> 
> org.apache.drill.exec.physical.impl.ScreenCreator$ScreenRoot.innerNext():79
> org.apache.drill.exec.physical.impl.BaseRootExec.next():73
> org.apache.drill.exec.work.fragment.FragmentExecutor$1.run():261
> org.apache.drill.exec.work.fragment.FragmentExecutor$1.run():255
> java.security.AccessController.doPrivileged():-2
> javax.security.auth.Subject.doAs():422
> org.apache.hadoop.security.UserGroupInformation.doAs():1566
> org.apache.drill.exec.work.fragment.FragmentExecutor.run():255
> org.apache.drill.common.SelfCleaningRunnable.run():38
> java.util.concurrent.ThreadPoolExecutor.runWorker():1142
> java.util.concurrent.ThreadPoolExecutor$Worker.run():617
> java.lang.Thread.run():745 (state=,code=0)
> {code}
> Also "skip.footer.line.count" should be taken into account.
> If "skip.header.line.count" or "skip.footer.line.count" has incorrect value 
> in Hive, throw appropriate exception in Drill.
> Ex: Hive table property skip.header.line.count value 'someValue' is 
> non-numeric



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (DRILL-3688) Drill should honor "skip.header.line.count" and "skip.footer.line.count" attributes of Hive table

[Arina Ielchiieva (JIRA)]

[ 
https://issues.apache.org/jira/browse/DRILL-3688?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15173392#comment-15173392
 ] 

Arina Ielchiieva commented on DRILL-3688:
-

Fixed in 84ce21c.

> Drill should honor "skip.header.line.count" and "skip.footer.line.count" 
> attributes of Hive table
> -
>
> Key: DRILL-3688
> URL: https://issues.apache.org/jira/browse/DRILL-3688
> Project: Apache Drill
>  Issue Type: Bug
>  Components: Storage - Hive
>Affects Versions: 1.1.0
> Environment: 1.1
>Reporter: Hao Zhu
>Assignee: Arina Ielchiieva
> Fix For: 1.6.0
>
>
> Currently Drill does not honor the "skip.header.line.count" attribute of Hive 
> table.
> It may cause some other format conversion issue.
> Reproduce:
> 1. Create a Hive table
> {code}
> create table h1db.testheader(col0 string)
> ROW FORMAT DELIMITED FIELDS TERMINATED BY '|'
> STORED AS TEXTFILE
> tblproperties("skip.header.line.count"="1");
> {code}
> 2. Prepare a sample data:
> {code}
> # cat test.data
> col0
> 2015-01-01
> {code}
> 3. Load sample data into Hive
> {code}
> LOAD DATA LOCAL INPATH '/xxx/test.data' OVERWRITE INTO TABLE h1db.testheader;
> {code}
> 4. Hive
> {code}
> hive> select * from h1db.testheader ;
> OK
> 2015-01-01
> Time taken: 0.254 seconds, Fetched: 1 row(s)
> {code}
> 5. Drill
> {code}
> >  select * from hive.h1db.testheader ;
> +-+
> |col0 |
> +-+
> | col0|
> | 2015-01-01  |
> +-+
> 2 rows selected (0.257 seconds)
> > select cast(col0 as date) from hive.h1db.testheader ;
> Error: SYSTEM ERROR: IllegalFieldValueException: Value 0 for monthOfYear must 
> be in the range [1,12]
> Fragment 0:0
> [Error Id: 34353702-ca27-440b-a4f4-0c9f79fc8ccd on h1.poc.com:31010]
>   (org.joda.time.IllegalFieldValueException) Value 0 for monthOfYear must be 
> in the range [1,12]
> org.joda.time.field.FieldUtils.verifyValueBounds():236
> org.joda.time.chrono.BasicChronology.getDateMidnightMillis():613
> org.joda.time.chrono.BasicChronology.getDateTimeMillis():159
> org.joda.time.chrono.AssembledChronology.getDateTimeMillis():120
> org.apache.drill.exec.expr.fn.impl.StringFunctionHelpers.memGetDate():261
> org.apache.drill.exec.expr.fn.impl.StringFunctionHelpers.getDate():218
> org.apache.drill.exec.test.generated.ProjectorGen0.doEval():67
> org.apache.drill.exec.test.generated.ProjectorGen0.projectRecords():62
> 
> org.apache.drill.exec.physical.impl.project.ProjectRecordBatch.doWork():172
> org.apache.drill.exec.record.AbstractSingleRecordBatch.innerNext():93
> 
> org.apache.drill.exec.physical.impl.project.ProjectRecordBatch.innerNext():129
> org.apache.drill.exec.record.AbstractRecordBatch.next():147
> org.apache.drill.exec.physical.impl.BaseRootExec.next():83
> 
> org.apache.drill.exec.physical.impl.ScreenCreator$ScreenRoot.innerNext():79
> org.apache.drill.exec.physical.impl.BaseRootExec.next():73
> org.apache.drill.exec.work.fragment.FragmentExecutor$1.run():261
> org.apache.drill.exec.work.fragment.FragmentExecutor$1.run():255
> java.security.AccessController.doPrivileged():-2
> javax.security.auth.Subject.doAs():422
> org.apache.hadoop.security.UserGroupInformation.doAs():1566
> org.apache.drill.exec.work.fragment.FragmentExecutor.run():255
> org.apache.drill.common.SelfCleaningRunnable.run():38
> java.util.concurrent.ThreadPoolExecutor.runWorker():1142
> java.util.concurrent.ThreadPoolExecutor$Worker.run():617
> java.lang.Thread.run():745 (state=,code=0)
> {code}
> Also "skip.footer.line.count" should be taken into account.
> If "skip.header.line.count" or "skip.footer.line.count" has incorrect value 
> in Hive, throw appropriate exception in Drill.
> Ex: Hive table property skip.header.line.count value 'someValue' is 
> non-numeric



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (DRILL-3745) Hive CHAR not supported

[Arina Ielchiieva (JIRA)]

[ 
https://issues.apache.org/jira/browse/DRILL-3745?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15173385#comment-15173385
 ] 

Arina Ielchiieva commented on DRILL-3745:
-

Totally agree, usually in Hive for strings check is done either for 
PrimitiveGrouping.STRING_GROUP (ex; concat_ws function), or explicitly for each 
string type (ex: PrimitiveCategory.STRING, PrimitiveCategory.CHAR, 
PrimitiveCategory.VARCHAR in translate function).
If code looks good, I'll create pull request then.

> Hive CHAR not supported
> ---
>
> Key: DRILL-3745
> URL: https://issues.apache.org/jira/browse/DRILL-3745
> Project: Apache Drill
>  Issue Type: Bug
>Affects Versions: 1.1.0
>Reporter: Nathaniel Auvil
>Assignee: Arina Ielchiieva
>
> It doesn’t look like Drill 1.1.0 supports the Hive CHAR type?
> In Hive:
> create table development.foo
> (
>   bad CHAR(10)
> );
> And then in sqlline:
> > use `hive.development`;
> > select * from foo;
> Error: PARSE ERROR: Unsupported Hive data type CHAR.
> Following Hive data types are supported in Drill INFORMATION_SCHEMA:
> BOOLEAN, BYTE, SHORT, INT, LONG, FLOAT, DOUBLE, DATE, TIMESTAMP,
> BINARY, DECIMAL, STRING, VARCHAR, LIST, MAP, STRUCT and UNION
> [Error Id: 58bf3940-3c09-4ad2-8f52-d052dffd4b17 on dtpg05:31010] 
> (state=,code=0)
> This was originally found when getting failures trying to connect via JDBS 
> using Squirrel.  We have the Hive plugin enabled with tables using CHAR.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (DRILL-4455) Depend on Apache Arrow for Vector and Memory

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/DRILL-4455?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15173072#comment-15173072
 ] 

ASF GitHub Bot commented on DRILL-4455:
---

GitHub user StevenMPhillips opened a pull request:

https://github.com/apache/drill/pull/398

DRILL-4455: Depend on Apache Arrow

Remove the vector and memory modules
Replace most instances of TypeProtos.MajorType, TypeProtos.MinorType etc
  with corresponding org.apache.arrow.types.Types class.
The code for serializing and deserializing vectors is still in the Drill 
code-base
  and still uses the old TypeProtos classes. The class MajorTypeHelper is 
used
  to convert between the two sets of classes.
The old load and getMetadata classes in ValueVector are now found in a 
corresponding
  ValueVectorHelper class

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/StevenMPhillips/drill arrow9

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/drill/pull/398.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #398


commit 91790c43f2939a028e05f8c67093d43e96fe9caa
Author: Steven Phillips 
Date:   2016-03-01T01:05:23Z

DRILL-4455: Depend on Apache Arrow

Remove the vector and memory modules
Replace most instances of TypeProtos.MajorType, TypeProtos.MinorType etc
  with corresponding org.apache.arrow.types.Types class.
The code for serializing and deserializing vectors is still in the Drill 
code-base
  and still uses the old TypeProtos classes. The class MajorTypeHelper is 
used
  to convert between the two sets of classes.
The old load and getMetadata classes in ValueVector are now found in a 
corresponding
  ValueVectorHelper class




> Depend on Apache Arrow for Vector and Memory
> 
>
> Key: DRILL-4455
> URL: https://issues.apache.org/jira/browse/DRILL-4455
> Project: Apache Drill
>  Issue Type: Bug
>Reporter: Steven Phillips
>Assignee: Steven Phillips
> Fix For: 1.7.0
>
>
> The code for value vectors and memory has been split and contributed to the 
> apache arrow repository. In order to help this project advance, Drill should 
> depend on the arrow project instead of internal value vector code.
> This change will require recompiling any external code, such as UDFs and 
> StoragePlugins. The changes will mainly just involve renaming the classes to 
> the org.apache.arrow namespace.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (DRILL-4455) Depend on Apache Arrow for Vector and Memory

[Steven Phillips (JIRA)]

Steven Phillips created DRILL-4455:
--

 Summary: Depend on Apache Arrow for Vector and Memory
 Key: DRILL-4455
 URL: https://issues.apache.org/jira/browse/DRILL-4455
 Project: Apache Drill
  Issue Type: Bug
Reporter: Steven Phillips
Assignee: Steven Phillips
 Fix For: 1.7.0


The code for value vectors and memory has been split and contributed to the 
apache arrow repository. In order to help this project advance, Drill should 
depend on the arrow project instead of internal value vector code.

This change will require recompiling any external code, such as UDFs and 
StoragePlugins. The changes will mainly just involve renaming the classes to 
the org.apache.arrow namespace.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (DRILL-4441) IN operator does not work with Avro reader

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/DRILL-4441?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15172930#comment-15172930
 ] 

ASF GitHub Bot commented on DRILL-4441:
---

Github user StevenMPhillips commented on the pull request:

https://github.com/apache/drill/pull/393#issuecomment-190458332
  
+1


> IN operator does not work with Avro reader
> --
>
> Key: DRILL-4441
> URL: https://issues.apache.org/jira/browse/DRILL-4441
> Project: Apache Drill
>  Issue Type: Bug
>  Components: Storage - Avro
>Affects Versions: 1.5.0
> Environment: Ubuntu
>Reporter: Stefán Baxter
>Priority: Critical
> Fix For: 1.6.0
>
>
> IN operator simply does not work. 
> (And I find it interesting that Storage-Avro is not available here in Jira as 
> a Storage component)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (DRILL-4454) NPE on select with options when file does not exist

[Victoria Markman (JIRA)]

Victoria Markman created DRILL-4454:
---

 Summary: NPE on select with options when file does not exist
 Key: DRILL-4454
 URL: https://issues.apache.org/jira/browse/DRILL-4454
 Project: Apache Drill
  Issue Type: Bug
  Components: Execution - Codegen
Affects Versions: 1.6.0
Reporter: Victoria Markman


File t1.csv does not exist:

{code}
0: jdbc:drill:schema=dfs> SELECT * FROM TABLE(dfs.`t1.csv`(type => 'text', 
extractHeader => true));
Error: VALIDATION ERROR: java.lang.NullPointerException
[Error Id: 224773a5-045b-4436-8661-7cca2c4562c5 on atsqa4-135.qa.lab:31010] 
(state=,code=0)
{code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (DRILL-4447) Drill seems to ignore TO_DATE(timestamp) when used inside DISTINCT() and GROUP BY

[Ryan Clough (JIRA)]

[ 
https://issues.apache.org/jira/browse/DRILL-4447?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15172751#comment-15172751
 ] 

Ryan Clough commented on DRILL-4447:


[~jaltekruse] Thanks for the clarification on the to_char function, I had a 
feeling at least part of this might have been user error, but was hard to 
determine while focusing on the distinct/group by bug which was my main issue.

Glad to have caught a more serious bug though. I initially caught it while 
using it in a GROUP BY where my results were way bigger than I expected, and 
managed to discover it affected DISTINCT() while trying to investigate the 
GROUP BY issue. Happy to provide any additional info if needed!

> Drill seems to ignore TO_DATE(timestamp) when used inside DISTINCT() and 
> GROUP BY
> -
>
> Key: DRILL-4447
> URL: https://issues.apache.org/jira/browse/DRILL-4447
> Project: Apache Drill
>  Issue Type: Bug
>Affects Versions: 1.5.0
> Environment: Centos 6.2/Distributed/CDH5.4.9
>Reporter: Ryan Clough
>Assignee: Jason Altekruse
>Priority: Critical
> Attachments: timestamps.txt, timestamps_parquet.tar.gz
>
>
> The issue comes from a larger query, but I've managed to narrow it down to 
> what is a minimally reproducible issue.
> Given a list of timestamps (will attach files) associated with 3 days, We 
> want to select the distinct dates (total: 3 days) from this list. To do this, 
> I decided to use the TO_DATE function, which does exactly what I want it.
> Note, there are 47 distinct timestamps in the data set.
> {code:sql}
> jdbc:drill:> SELECT DISTINCT(TO_DATE(data_date)) AS data_date
> . . . . . . . > FROM timestamps;
> +-+
> |  data_date  |
> +-+
> | 2016-02-23  |
> | 2016-02-25  |
> | 2016-02-24  |
> | 2016-02-23  |
> | 2016-02-24  |
> | 2016-02-24  |
> | 2016-02-25  |
> | 2016-02-24  |
> | 2016-02-24  |
> | 2016-02-23  |
> | 2016-02-25  |
> | 2016-02-23  |
> | 2016-02-24  |
> | 2016-02-25  |
> | 2016-02-23  |
> | 2016-02-24  |
> | 2016-02-24  |
> | 2016-02-24  |
> | 2016-02-23  |
> | 2016-02-25  |
> | 2016-02-25  |
> | 2016-02-25  |
> | 2016-02-25  |
> | 2016-02-23  |
> | 2016-02-23  |
> | 2016-02-23  |
> | 2016-02-23  |
> | 2016-02-24  |
> | 2016-02-25  |
> | 2016-02-25  |
> | 2016-02-24  |
> | 2016-02-24  |
> | 2016-02-23  |
> | 2016-02-24  |
> | 2016-02-25  |
> | 2016-02-25  |
> | 2016-02-23  |
> | 2016-02-25  |
> | 2016-02-25  |
> | 2016-02-25  |
> | 2016-02-23  |
> | 2016-02-24  |
> | 2016-02-23  |
> | 2016-02-24  |
> | 2016-02-24  |
> | 2016-02-23  |
> | 2016-02-23  |
> +-+
> 47 rows selected (11.057 seconds)
> {code}
> As you can see, DRILL has ignored the TO_DATE function when checking for 
> distinct records (note that the 47 rows matches the 47 rows of distinct 
> timestamps).
> My testing has also shown that this affect GROUP BY. I wouldn't be surprised 
> if it manifested its self elsewhere.
> I tried to get around the problem by converting the dates to a string using 
> TO_CHAR: surely drill will use the resulting strings to do the DISTINCT 
> comparison?
> {code:sql}
> drill:> SELECT DISTINCT(TO_CHAR(TO_DATE(data_date))) FROM timestamps;
> Error: SYSTEM ERROR: SchemaChangeException: Failure while trying to 
> materialize incoming schema.  Errors:
> Error in expression at index -1.  Error: Missing function implementation: 
> [to_char(DATE-OPTIONAL)].  Full expression: --UNKNOWN EXPRESSION--..
> Fragment 0:0
> [Error Id: bcad87f0-3353-4a3b-842e-c68a02b394c3 on 
> lvimhdpa14.lv.vimeows.com:31010] (state=,code=0)
> {code}
> As far as I can tell from the docs, you SHOULD be able to convert a date to a 
> string with TO_CHAR(). I'm not sure what the underlying issue is here, but I 
> thought it good to report the issue.
> Please let me know if you need any further info, query plans, etc, but it 
> should be reproducable with the timestamps data I'll attach in a minute



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Assigned] (DRILL-4447) Drill seems to ignore TO_DATE(timestamp) when used inside DISTINCT() and GROUP BY

[Jason Altekruse (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DRILL-4447?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jason Altekruse reassigned DRILL-4447:
--

Assignee: Jason Altekruse

> Drill seems to ignore TO_DATE(timestamp) when used inside DISTINCT() and 
> GROUP BY
> -
>
> Key: DRILL-4447
> URL: https://issues.apache.org/jira/browse/DRILL-4447
> Project: Apache Drill
>  Issue Type: Bug
>Affects Versions: 1.5.0
> Environment: Centos 6.2/Distributed/CDH5.4.9
>Reporter: Ryan Clough
>Assignee: Jason Altekruse
>Priority: Critical
> Attachments: timestamps.txt, timestamps_parquet.tar.gz
>
>
> The issue comes from a larger query, but I've managed to narrow it down to 
> what is a minimally reproducible issue.
> Given a list of timestamps (will attach files) associated with 3 days, We 
> want to select the distinct dates (total: 3 days) from this list. To do this, 
> I decided to use the TO_DATE function, which does exactly what I want it.
> Note, there are 47 distinct timestamps in the data set.
> {code:sql}
> jdbc:drill:> SELECT DISTINCT(TO_DATE(data_date)) AS data_date
> . . . . . . . > FROM timestamps;
> +-+
> |  data_date  |
> +-+
> | 2016-02-23  |
> | 2016-02-25  |
> | 2016-02-24  |
> | 2016-02-23  |
> | 2016-02-24  |
> | 2016-02-24  |
> | 2016-02-25  |
> | 2016-02-24  |
> | 2016-02-24  |
> | 2016-02-23  |
> | 2016-02-25  |
> | 2016-02-23  |
> | 2016-02-24  |
> | 2016-02-25  |
> | 2016-02-23  |
> | 2016-02-24  |
> | 2016-02-24  |
> | 2016-02-24  |
> | 2016-02-23  |
> | 2016-02-25  |
> | 2016-02-25  |
> | 2016-02-25  |
> | 2016-02-25  |
> | 2016-02-23  |
> | 2016-02-23  |
> | 2016-02-23  |
> | 2016-02-23  |
> | 2016-02-24  |
> | 2016-02-25  |
> | 2016-02-25  |
> | 2016-02-24  |
> | 2016-02-24  |
> | 2016-02-23  |
> | 2016-02-24  |
> | 2016-02-25  |
> | 2016-02-25  |
> | 2016-02-23  |
> | 2016-02-25  |
> | 2016-02-25  |
> | 2016-02-25  |
> | 2016-02-23  |
> | 2016-02-24  |
> | 2016-02-23  |
> | 2016-02-24  |
> | 2016-02-24  |
> | 2016-02-23  |
> | 2016-02-23  |
> +-+
> 47 rows selected (11.057 seconds)
> {code}
> As you can see, DRILL has ignored the TO_DATE function when checking for 
> distinct records (note that the 47 rows matches the 47 rows of distinct 
> timestamps).
> My testing has also shown that this affect GROUP BY. I wouldn't be surprised 
> if it manifested its self elsewhere.
> I tried to get around the problem by converting the dates to a string using 
> TO_CHAR: surely drill will use the resulting strings to do the DISTINCT 
> comparison?
> {code:sql}
> drill:> SELECT DISTINCT(TO_CHAR(TO_DATE(data_date))) FROM timestamps;
> Error: SYSTEM ERROR: SchemaChangeException: Failure while trying to 
> materialize incoming schema.  Errors:
> Error in expression at index -1.  Error: Missing function implementation: 
> [to_char(DATE-OPTIONAL)].  Full expression: --UNKNOWN EXPRESSION--..
> Fragment 0:0
> [Error Id: bcad87f0-3353-4a3b-842e-c68a02b394c3 on 
> lvimhdpa14.lv.vimeows.com:31010] (state=,code=0)
> {code}
> As far as I can tell from the docs, you SHOULD be able to convert a date to a 
> string with TO_CHAR(). I'm not sure what the underlying issue is here, but I 
> thought it good to report the issue.
> Please let me know if you need any further info, query plans, etc, but it 
> should be reproducable with the timestamps data I'll attach in a minute



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (DRILL-4447) Drill seems to ignore TO_DATE(timestamp) when used inside DISTINCT() and GROUP BY

[Jason Altekruse (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DRILL-4447?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jason Altekruse updated DRILL-4447:
---
Priority: Critical  (was: Major)

> Drill seems to ignore TO_DATE(timestamp) when used inside DISTINCT() and 
> GROUP BY
> -
>
> Key: DRILL-4447
> URL: https://issues.apache.org/jira/browse/DRILL-4447
> Project: Apache Drill
>  Issue Type: Bug
>Affects Versions: 1.5.0
> Environment: Centos 6.2/Distributed/CDH5.4.9
>Reporter: Ryan Clough
>Priority: Critical
> Attachments: timestamps.txt, timestamps_parquet.tar.gz
>
>
> The issue comes from a larger query, but I've managed to narrow it down to 
> what is a minimally reproducible issue.
> Given a list of timestamps (will attach files) associated with 3 days, We 
> want to select the distinct dates (total: 3 days) from this list. To do this, 
> I decided to use the TO_DATE function, which does exactly what I want it.
> Note, there are 47 distinct timestamps in the data set.
> {code:sql}
> jdbc:drill:> SELECT DISTINCT(TO_DATE(data_date)) AS data_date
> . . . . . . . > FROM timestamps;
> +-+
> |  data_date  |
> +-+
> | 2016-02-23  |
> | 2016-02-25  |
> | 2016-02-24  |
> | 2016-02-23  |
> | 2016-02-24  |
> | 2016-02-24  |
> | 2016-02-25  |
> | 2016-02-24  |
> | 2016-02-24  |
> | 2016-02-23  |
> | 2016-02-25  |
> | 2016-02-23  |
> | 2016-02-24  |
> | 2016-02-25  |
> | 2016-02-23  |
> | 2016-02-24  |
> | 2016-02-24  |
> | 2016-02-24  |
> | 2016-02-23  |
> | 2016-02-25  |
> | 2016-02-25  |
> | 2016-02-25  |
> | 2016-02-25  |
> | 2016-02-23  |
> | 2016-02-23  |
> | 2016-02-23  |
> | 2016-02-23  |
> | 2016-02-24  |
> | 2016-02-25  |
> | 2016-02-25  |
> | 2016-02-24  |
> | 2016-02-24  |
> | 2016-02-23  |
> | 2016-02-24  |
> | 2016-02-25  |
> | 2016-02-25  |
> | 2016-02-23  |
> | 2016-02-25  |
> | 2016-02-25  |
> | 2016-02-25  |
> | 2016-02-23  |
> | 2016-02-24  |
> | 2016-02-23  |
> | 2016-02-24  |
> | 2016-02-24  |
> | 2016-02-23  |
> | 2016-02-23  |
> +-+
> 47 rows selected (11.057 seconds)
> {code}
> As you can see, DRILL has ignored the TO_DATE function when checking for 
> distinct records (note that the 47 rows matches the 47 rows of distinct 
> timestamps).
> My testing has also shown that this affect GROUP BY. I wouldn't be surprised 
> if it manifested its self elsewhere.
> I tried to get around the problem by converting the dates to a string using 
> TO_CHAR: surely drill will use the resulting strings to do the DISTINCT 
> comparison?
> {code:sql}
> drill:> SELECT DISTINCT(TO_CHAR(TO_DATE(data_date))) FROM timestamps;
> Error: SYSTEM ERROR: SchemaChangeException: Failure while trying to 
> materialize incoming schema.  Errors:
> Error in expression at index -1.  Error: Missing function implementation: 
> [to_char(DATE-OPTIONAL)].  Full expression: --UNKNOWN EXPRESSION--..
> Fragment 0:0
> [Error Id: bcad87f0-3353-4a3b-842e-c68a02b394c3 on 
> lvimhdpa14.lv.vimeows.com:31010] (state=,code=0)
> {code}
> As far as I can tell from the docs, you SHOULD be able to convert a date to a 
> string with TO_CHAR(). I'm not sure what the underlying issue is here, but I 
> thought it good to report the issue.
> Please let me know if you need any further info, query plans, etc, but it 
> should be reproducable with the timestamps data I'll attach in a minute



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (DRILL-4447) Drill seems to ignore TO_DATE(timestamp) when used inside DISTINCT() and GROUP BY

[Jason Altekruse (JIRA)]

[ 
https://issues.apache.org/jira/browse/DRILL-4447?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15172690#comment-15172690
 ] 

Jason Altekruse commented on DRILL-4447:


Couple of things here, the reason that the to_char function was not found is 
that it actually requires a second parameter to specify the desired format. 
More info can be found on this doc page: 
https://drill.apache.org/docs/data-type-conversion/#to_char

Using to_char correctly I was able to get the 3 distinct values back int he 
query, but your original query looks like a bug running a distinct aggregate 
over date values. I am going to raise the priority as this is a wrong result 
issue and try to look into it soon.

I do not understand why writing the data out to a file changes the result of 
the aggregation, that seems pretty puzzling.



> Drill seems to ignore TO_DATE(timestamp) when used inside DISTINCT() and 
> GROUP BY
> -
>
> Key: DRILL-4447
> URL: https://issues.apache.org/jira/browse/DRILL-4447
> Project: Apache Drill
>  Issue Type: Bug
>Affects Versions: 1.5.0
> Environment: Centos 6.2/Distributed/CDH5.4.9
>Reporter: Ryan Clough
> Attachments: timestamps.txt, timestamps_parquet.tar.gz
>
>
> The issue comes from a larger query, but I've managed to narrow it down to 
> what is a minimally reproducible issue.
> Given a list of timestamps (will attach files) associated with 3 days, We 
> want to select the distinct dates (total: 3 days) from this list. To do this, 
> I decided to use the TO_DATE function, which does exactly what I want it.
> Note, there are 47 distinct timestamps in the data set.
> {code:sql}
> jdbc:drill:> SELECT DISTINCT(TO_DATE(data_date)) AS data_date
> . . . . . . . > FROM timestamps;
> +-+
> |  data_date  |
> +-+
> | 2016-02-23  |
> | 2016-02-25  |
> | 2016-02-24  |
> | 2016-02-23  |
> | 2016-02-24  |
> | 2016-02-24  |
> | 2016-02-25  |
> | 2016-02-24  |
> | 2016-02-24  |
> | 2016-02-23  |
> | 2016-02-25  |
> | 2016-02-23  |
> | 2016-02-24  |
> | 2016-02-25  |
> | 2016-02-23  |
> | 2016-02-24  |
> | 2016-02-24  |
> | 2016-02-24  |
> | 2016-02-23  |
> | 2016-02-25  |
> | 2016-02-25  |
> | 2016-02-25  |
> | 2016-02-25  |
> | 2016-02-23  |
> | 2016-02-23  |
> | 2016-02-23  |
> | 2016-02-23  |
> | 2016-02-24  |
> | 2016-02-25  |
> | 2016-02-25  |
> | 2016-02-24  |
> | 2016-02-24  |
> | 2016-02-23  |
> | 2016-02-24  |
> | 2016-02-25  |
> | 2016-02-25  |
> | 2016-02-23  |
> | 2016-02-25  |
> | 2016-02-25  |
> | 2016-02-25  |
> | 2016-02-23  |
> | 2016-02-24  |
> | 2016-02-23  |
> | 2016-02-24  |
> | 2016-02-24  |
> | 2016-02-23  |
> | 2016-02-23  |
> +-+
> 47 rows selected (11.057 seconds)
> {code}
> As you can see, DRILL has ignored the TO_DATE function when checking for 
> distinct records (note that the 47 rows matches the 47 rows of distinct 
> timestamps).
> My testing has also shown that this affect GROUP BY. I wouldn't be surprised 
> if it manifested its self elsewhere.
> I tried to get around the problem by converting the dates to a string using 
> TO_CHAR: surely drill will use the resulting strings to do the DISTINCT 
> comparison?
> {code:sql}
> drill:> SELECT DISTINCT(TO_CHAR(TO_DATE(data_date))) FROM timestamps;
> Error: SYSTEM ERROR: SchemaChangeException: Failure while trying to 
> materialize incoming schema.  Errors:
> Error in expression at index -1.  Error: Missing function implementation: 
> [to_char(DATE-OPTIONAL)].  Full expression: --UNKNOWN EXPRESSION--..
> Fragment 0:0
> [Error Id: bcad87f0-3353-4a3b-842e-c68a02b394c3 on 
> lvimhdpa14.lv.vimeows.com:31010] (state=,code=0)
> {code}
> As far as I can tell from the docs, you SHOULD be able to convert a date to a 
> string with TO_CHAR(). I'm not sure what the underlying issue is here, but I 
> thought it good to report the issue.
> Please let me know if you need any further info, query plans, etc, but it 
> should be reproducable with the timestamps data I'll attach in a minute



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (DRILL-4437) Implement framework for testing operators in isolation

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/DRILL-4437?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15172480#comment-15172480
 ] 

ASF GitHub Bot commented on DRILL-4437:
---

Github user jaltekruse commented on the pull request:

https://github.com/apache/drill/pull/394#issuecomment-190353355
  
@sudheeshkatkam @parthchandra @adeneche @StevenMPhillips Would any of you 
be able to do a review?


> Implement framework for testing operators in isolation
> --
>
> Key: DRILL-4437
> URL: https://issues.apache.org/jira/browse/DRILL-4437
> Project: Apache Drill
>  Issue Type: Test
>  Components: Tools, Build & Test
>Reporter: Jason Altekruse
>Assignee: Jason Altekruse
> Fix For: 1.6.0
>
>
> Most of the tests written for Drill are end-to-end. We spin up a full 
> instance of the server, submit one or more SQL queries and check the results.
> While integration tests like this are useful for ensuring that all features 
> are guaranteed to not break end-user functionality overuse of this approach 
> has caused a number of pain points.
> Overall the tests end up running a lot of the exact same code, parsing and 
> planning many similar queries.
> Creating consistent reproductions of issues, especially edge cases found in 
> clustered environments can be extremely difficult. Even the simpler case of 
> testing cases where operators are able to handle a particular series of 
> incoming batches of records has required hacks like generating large enough 
> files so that the scanners happen to break them up into separate batches. 
> These tests are brittle as they make assumptions about how the scanners will 
> work in the future. An example of when this could break, we might do perf 
> evaluation to find out we should be producing larger batches in some cases. 
> Existing tests that are trying to test multiple batches by producing a few 
> more records than the current threshold for batch size would not be testing 
> the same code paths.
> We need to make more parts of the system testable without initializing the 
> entire Drill server, as well as making the different internal settings and 
> state of the server configurable for tests.
> This is a first effort to enable testing the physical operators in Drill by 
> mocking the components of the system necessary to enable operators to 
> initialize and execute.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (DRILL-3745) Hive CHAR not supported

[Venki Korukanti (JIRA)]

[ 
https://issues.apache.org/jira/browse/DRILL-3745?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15172292#comment-15172292
 ] 

Venki Korukanti commented on DRILL-3745:


Yeah the types don't have exact one to one mapping between Drill and Hive. Hive 
UDFs I have seen usually have implicit casting or if it handles CHAR as input 
it can handle VARCHAR also as input. 

> Hive CHAR not supported
> ---
>
> Key: DRILL-3745
> URL: https://issues.apache.org/jira/browse/DRILL-3745
> Project: Apache Drill
>  Issue Type: Bug
>Affects Versions: 1.1.0
>Reporter: Nathaniel Auvil
>Assignee: Arina Ielchiieva
>
> It doesn’t look like Drill 1.1.0 supports the Hive CHAR type?
> In Hive:
> create table development.foo
> (
>   bad CHAR(10)
> );
> And then in sqlline:
> > use `hive.development`;
> > select * from foo;
> Error: PARSE ERROR: Unsupported Hive data type CHAR.
> Following Hive data types are supported in Drill INFORMATION_SCHEMA:
> BOOLEAN, BYTE, SHORT, INT, LONG, FLOAT, DOUBLE, DATE, TIMESTAMP,
> BINARY, DECIMAL, STRING, VARCHAR, LIST, MAP, STRUCT and UNION
> [Error Id: 58bf3940-3c09-4ad2-8f52-d052dffd4b17 on dtpg05:31010] 
> (state=,code=0)
> This was originally found when getting failures trying to connect via JDBS 
> using Squirrel.  We have the Hive plugin enabled with tables using CHAR.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (DRILL-3745) Hive CHAR not supported

[Arina Ielchiieva (JIRA)]

[ 
https://issues.apache.org/jira/browse/DRILL-3745?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15172152#comment-15172152
 ] 

Arina Ielchiieva commented on DRILL-3745:
-

[Venki 
Korukanti|https://issues.apache.org/jira/secure/ViewProfile.jspa?name=vkorukanti],
 I have added char support in Hive UDFs but it's only applicable for udf return 
type.
When char is udf return type, we convert it to varchar, that's simple here.
But we'll get an error if udf expects char as input parameter since Drill has 
varchar holder for both char and varchar and it's impossible to determine which 
one it is.

Link - 
https://github.com/arina-ielchiieva/drill/commit/1a167efecf73b2b6e91585798914a79237b68534
 

> Hive CHAR not supported
> ---
>
> Key: DRILL-3745
> URL: https://issues.apache.org/jira/browse/DRILL-3745
> Project: Apache Drill
>  Issue Type: Bug
>Affects Versions: 1.1.0
>Reporter: Nathaniel Auvil
>Assignee: Arina Ielchiieva
>
> It doesn’t look like Drill 1.1.0 supports the Hive CHAR type?
> In Hive:
> create table development.foo
> (
>   bad CHAR(10)
> );
> And then in sqlline:
> > use `hive.development`;
> > select * from foo;
> Error: PARSE ERROR: Unsupported Hive data type CHAR.
> Following Hive data types are supported in Drill INFORMATION_SCHEMA:
> BOOLEAN, BYTE, SHORT, INT, LONG, FLOAT, DOUBLE, DATE, TIMESTAMP,
> BINARY, DECIMAL, STRING, VARCHAR, LIST, MAP, STRUCT and UNION
> [Error Id: 58bf3940-3c09-4ad2-8f52-d052dffd4b17 on dtpg05:31010] 
> (state=,code=0)
> This was originally found when getting failures trying to connect via JDBS 
> using Squirrel.  We have the Hive plugin enabled with tables using CHAR.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (DRILL-4404) Java NPE. Unexpected exception during fragment initialization

[Taras Supyk (JIRA)]

[ 
https://issues.apache.org/jira/browse/DRILL-4404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15171855#comment-15171855
 ] 

Taras Supyk commented on DRILL-4404:


Can't reproduce

> Java NPE.  Unexpected exception during fragment initialization
> --
>
> Key: DRILL-4404
> URL: https://issues.apache.org/jira/browse/DRILL-4404
> Project: Apache Drill
>  Issue Type: Bug
>  Components:  Server
>Affects Versions: 1.5.0
>Reporter: N Campbell
>Assignee: Taras Supyk
>
> Error: SYSTEM ERROR: NullPointerException
> [Error Id: a290df2c-d3ff-4229-bf26-50d0b6992d77 on centos1:31010]
>   (org.apache.drill.exec.work.foreman.ForemanException) Unexpected exception 
> during fragment initialization: Internal error: Error while applying rule 
> ReduceExpressionsRule_Project, args 
> [rel#830960:LogicalProject.NONE.ANY([]).[](input=rel#830959:Subset#0.JDBC.postgres.ANY([]).[],EXPR$0=-(*(2,
>  2)))]
> org.apache.drill.exec.work.foreman.Foreman.run():261
> java.util.concurrent.ThreadPoolExecutor.runWorker():1142
> java.util.concurrent.ThreadPoolExecutor$Worker.run():617
> java.lang.Thread.run():745
>   Caused By (java.lang.AssertionError) Internal error: Error while applying 
> rule ReduceExpressionsRule_Project, args 
> [rel#830960:LogicalProject.NONE.ANY([]).[](input=rel#830959:Subset#0.JDBC.postgres.ANY([]).[],EXPR$0=-(*(2,
>  2)))]
> org.apache.calcite.util.Util.newInternal():792
> org.apache.calcite.plan.volcano.VolcanoRuleCall.onMatch():251
> org.apache.calcite.plan.volcano.VolcanoPlanner.findBestExp():808
> org.apache.calcite.tools.Programs$RuleSetProgram.run():303
> org.apache.calcite.prepare.PlannerImpl.transform():313
> 
> org.apache.drill.exec.planner.sql.handlers.DefaultSqlHandler.doLogicalPlanning():542
> 
> org.apache.drill.exec.planner.sql.handlers.DefaultSqlHandler.convertToDrel():218
> 
> org.apache.drill.exec.planner.sql.handlers.DefaultSqlHandler.convertToDrel():252
> org.apache.drill.exec.planner.sql.handlers.DefaultSqlHandler.getPlan():172
> org.apache.drill.exec.planner.sql.DrillSqlWorker.getPlan():199
> org.apache.drill.exec.work.foreman.Foreman.runSQL():924
> org.apache.drill.exec.work.foreman.Foreman.run():250
> java.util.concurrent.ThreadPoolExecutor.runWorker():1142
> java.util.concurrent.ThreadPoolExecutor$Worker.run():617
> java.lang.Thread.run():745
>   Caused By (java.lang.NullPointerException) null
> 
> org.apache.drill.exec.planner.logical.DrillOptiq$RexToDrill.visitCall():131
> org.apache.drill.exec.planner.logical.DrillOptiq$RexToDrill.visitCall():79
> org.apache.calcite.rex.RexCall.accept():107
> org.apache.drill.exec.planner.logical.DrillOptiq.toDrill():76
> org.apache.drill.exec.planner.logical.DrillConstExecutor.reduce():162
> org.apache.calcite.rel.rules.ReduceExpressionsRule.reduceExpressions():499
> org.apache.calcite.rel.rules.ReduceExpressionsRule$1.onMatch():241
> org.apache.calcite.plan.volcano.VolcanoRuleCall.onMatch():228
> org.apache.calcite.plan.volcano.VolcanoPlanner.findBestExp():808
> org.apache.calcite.tools.Programs$RuleSetProgram.run():303
> org.apache.calcite.prepare.PlannerImpl.transform():313
> 
> org.apache.drill.exec.planner.sql.handlers.DefaultSqlHandler.doLogicalPlanning():542
> 
> org.apache.drill.exec.planner.sql.handlers.DefaultSqlHandler.convertToDrel():218
> 
> org.apache.drill.exec.planner.sql.handlers.DefaultSqlHandler.convertToDrel():252
> org.apache.drill.exec.planner.sql.handlers.DefaultSqlHandler.getPlan():172
> org.apache.drill.exec.planner.sql.DrillSqlWorker.getPlan():199
> org.apache.drill.exec.work.foreman.Foreman.runSQL():924
> org.apache.drill.exec.work.foreman.Foreman.run():250
> java.util.concurrent.ThreadPoolExecutor.runWorker():1142
> java.util.concurrent.ThreadPoolExecutor$Worker.run():617
> java.lang.Thread.run():745
> SQLState:  null
> ErrorCode: 0



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (DRILL-4453) Difference in results over char data, window function query

[Khurram Faraaz (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DRILL-4453?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Khurram Faraaz updated DRILL-4453:
--
Description: 
Window function query with frame clause returns results that are different from 
those returned by same query on Postgres 9.3 of same data.

Note that the two tables have same number of nulls in both Drill and Postgres.

The length of the result returned by MIN function is different on Postgres 9.3 
vs Drill 1.6.0
{noformat}
Drill 1.6.0 => returns 1 as length.

0: jdbc:drill:schema=dfs.tmp> select length(min(c4)) from dfs.tmp.`t_alltype`;
+-+
| EXPR$0  |
+-+
| 1   |
+-+
1 row selected (0.282 seconds)

Postgress 9.3 returns 0 as lenght.

postgres=# select length(min(c4)) from t_alltype;
 length

  0
(1 row)
{noformat}

{noformat}
postgres=# \d t_alltype
 Table "public.t_alltype"
 Column |Type | Modifiers
+-+---
 c1 | integer |
 c2 | integer |
 c3 | bigint  |
 c4 | character(256)  |
 c5 | character varying(256)  |
 c6 | timestamp without time zone |
 c7 | date|
 c8 | boolean |
 c9 | double precision|
postgres=# select c4 from t_alltype where c4 is null;
 c4




(3 rows)

{noformat}
postgres=# SELECT MIN(c4) OVER(PARTITION BY c8 ORDER BY c1 ROWS BETWEEN 
UNBOUNDED PRECEDING AND CURRENT ROW) FROM t_alltype;

   min
--
 gwfrW
 ZAFOcferhjkcl
 ZAFOcferhjkcl
 ZAFOcferhjkcl
 ZAFOcferhjkcl
 ...
 ...
 
 ApKK
 ApKK















(145 rows)
{noformat}

Parquet schema details

{noformat}
[root@centos-01 parquet-tools]# ./parquet-schema 
./Datasources/window_functions/t_alltype.parquet
message root {
  optional int32 c1;
  optional int32 c2;
  optional int64 c3;
  optional binary c4 (UTF8);
  optional binary c5 (UTF8);
  optional int64 c6 (TIMESTAMP_MILLIS);
  optional int32 c7 (DATE);
  optional boolean c8;
  optional double c9;
}
{noformat}

On Drill 1.6.0 

{noformat}
0: jdbc:drill:schema=dfs.tmp> SELECT MIN(c4) OVER(PARTITION BY c8 ORDER BY c1 
ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW) FROM dfs.tmp.`t_alltype`;
++
| EXPR$0 |
++
| gwfrW  |
| ZAFOcferhjkcl  |
| ZAFOcferhjkcl  |
| ZAFOcferhjkcl  |
| ZAFOcferhjkcl  |
...
...
| ApKK |
| ApKK |
|  |
|  |
|  |
|  |
|  |
|  |
|  |
|  |
|  |
|  |
| null |
| null |
|  |
|  |
|  |
+--+
145 rows selected (0.409 seconds)
{noformat}

  was:
Window function query with frame clause returns results that are different from 
those returned by same query on Postgres 9.3 of same data.

The difference is that there are two extra nulls returned by Drill where as 
Postgres does not. Note that the two tables have same number of nulls in both 
Drill and Postgres.

{noformat}
postgres=# \d t_alltype
 Table "public.t_alltype"
 Column |Type | Modifiers
+-+---
 c1 | integer |
 c2 | integer |
 c3 | bigint  |
 c4 | character(256)  |
 c5 | character varying(256)  |
 c6 | timestamp without time zone |
 c7 | date|
 c8 | boolean |
 c9 | double precision|
postgres=# select c4 from t_alltype where c4 is null;
 c4




(3 rows)

{noformat}
postgres=# SELECT MIN(c4) OVER(PARTITION BY c8 ORDER BY c1 ROWS BETWEEN 
UNBOUNDED PRECEDING AND CURRENT ROW) FROM t_alltype;

   min

[jira] [Updated] (DRILL-4453) Difference in results over char data, window function query

[Khurram Faraaz (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DRILL-4453?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Khurram Faraaz updated DRILL-4453:
--
Attachment: t_alltype.parquet
t_alltype.csv

Attached CSV file used on Postgres and parquet file used on Drill.

> Difference in results over char data, window function query
> ---
>
> Key: DRILL-4453
> URL: https://issues.apache.org/jira/browse/DRILL-4453
> Project: Apache Drill
>  Issue Type: Bug
>  Components: Execution - Flow
>Affects Versions: 1.6.0
> Environment: 4 node cluster
>Reporter: Khurram Faraaz
>  Labels: window_function
> Attachments: t_alltype.csv, t_alltype.parquet
>
>
> Window function query with frame clause returns results that are different 
> from those returned by same query on Postgres 9.3 of same data.
> The difference is that there are two extra nulls returned by Drill where as 
> Postgres does not. Note that the two tables have same number of nulls in both 
> Drill and Postgres.
> {noformat}
> postgres=# \d t_alltype
>  Table "public.t_alltype"
>  Column |Type | Modifiers
> +-+---
>  c1 | integer |
>  c2 | integer |
>  c3 | bigint  |
>  c4 | character(256)  |
>  c5 | character varying(256)  |
>  c6 | timestamp without time zone |
>  c7 | date|
>  c8 | boolean |
>  c9 | double precision|
> postgres=# select c4 from t_alltype where c4 is null;
>  c4
> 
> (3 rows)
> {noformat}
> postgres=# SELECT MIN(c4) OVER(PARTITION BY c8 ORDER BY c1 ROWS BETWEEN 
> UNBOUNDED PRECEDING AND CURRENT ROW) FROM t_alltype;
>   
>  min
> --
>  gwfrW
>  ZAFOcferhjkcl
>  ZAFOcferhjkcl
>  ZAFOcferhjkcl
>  ZAFOcferhjkcl
>  ...
>  ...
>  
>  ApKK
>  ApKK
> (145 rows)
> {noformat}
> Parquet schema details
> {noformat}
> [root@centos-01 parquet-tools]# ./parquet-schema 
> ./Datasources/window_functions/t_alltype.parquet
> message root {
>   optional int32 c1;
>   optional int32 c2;
>   optional int64 c3;
>   optional binary c4 (UTF8);
>   optional binary c5 (UTF8);
>   optional int64 c6 (TIMESTAMP_MILLIS);
>   optional int32 c7 (DATE);
>   optional boolean c8;
>   optional double c9;
> }
> {noformat}
> On Drill 1.6.0 
> {noformat}
> 0: jdbc:drill:schema=dfs.tmp> SELECT MIN(c4) OVER(PARTITION BY c8 ORDER BY c1 
> ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW) FROM dfs.tmp.`t_alltype`;
> ++
> | EXPR$0 |
> ++
> | gwfrW  |
> | ZAFOcferhjkcl  |
> | ZAFOcferhjkcl  |
> | ZAFOcferhjkcl  |
> | ZAFOcferhjkcl  |
> ...
> ...
> | ApKK |
> | ApKK |
> |  |
> |  |
> |  |
> |  |
> |  |
> |  |
> |  |
> |  |
> |  |
> |  |
> | null |
> | null |
> |  |
> |  |
> |  |
> +--+
> 145 rows selected (0.409 seconds)
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (DRILL-4453) Difference in results over char data, window function query

[Khurram Faraaz (JIRA)]

Khurram Faraaz created DRILL-4453:
-

 Summary: Difference in results over char data, window function 
query
 Key: DRILL-4453
 URL: https://issues.apache.org/jira/browse/DRILL-4453
 Project: Apache Drill
  Issue Type: Bug
  Components: Execution - Flow
Affects Versions: 1.6.0
 Environment: 4 node cluster
Reporter: Khurram Faraaz


Window function query with frame clause returns results that are different from 
those returned by same query on Postgres 9.3 of same data.

The difference is that there are two extra nulls returned by Drill where as 
Postgres does not. Note that the two tables have same number of nulls in both 
Drill and Postgres.

{noformat}
postgres=# \d t_alltype
 Table "public.t_alltype"
 Column |Type | Modifiers
+-+---
 c1 | integer |
 c2 | integer |
 c3 | bigint  |
 c4 | character(256)  |
 c5 | character varying(256)  |
 c6 | timestamp without time zone |
 c7 | date|
 c8 | boolean |
 c9 | double precision|
postgres=# select c4 from t_alltype where c4 is null;
 c4




(3 rows)

{noformat}
postgres=# SELECT MIN(c4) OVER(PARTITION BY c8 ORDER BY c1 ROWS BETWEEN 
UNBOUNDED PRECEDING AND CURRENT ROW) FROM t_alltype;

   min
--
 gwfrW
 ZAFOcferhjkcl
 ZAFOcferhjkcl
 ZAFOcferhjkcl
 ZAFOcferhjkcl
 ...
 ...
 
 ApKK
 ApKK















(145 rows)
{noformat}

Parquet schema details

{noformat}
[root@centos-01 parquet-tools]# ./parquet-schema 
./Datasources/window_functions/t_alltype.parquet
message root {
  optional int32 c1;
  optional int32 c2;
  optional int64 c3;
  optional binary c4 (UTF8);
  optional binary c5 (UTF8);
  optional int64 c6 (TIMESTAMP_MILLIS);
  optional int32 c7 (DATE);
  optional boolean c8;
  optional double c9;
}
{noformat}

On Drill 1.6.0 

{noformat}
0: jdbc:drill:schema=dfs.tmp> SELECT MIN(c4) OVER(PARTITION BY c8 ORDER BY c1 
ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW) FROM dfs.tmp.`t_alltype`;
++
| EXPR$0 |
++
| gwfrW  |
| ZAFOcferhjkcl  |
| ZAFOcferhjkcl  |
| ZAFOcferhjkcl  |
| ZAFOcferhjkcl  |
...
...
| ApKK |
| ApKK |
|  |
|  |
|  |
|  |
|  |
|  |
|  |
|  |
|  |
|  |
| null |
| null |
|  |
|  |
|  |
+--+
145 rows selected (0.409 seconds)
{noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (DRILL-4399) query using OVERLAPS function executes and returns 0 rows

[Taras Supyk (JIRA)]

[ 
https://issues.apache.org/jira/browse/DRILL-4399?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15171714#comment-15171714
 ] 

Taras Supyk commented on DRILL-4399:


Confirmed, Same behavior as in DRILL-4409

> query using OVERLAPS function executes and returns 0 rows
> -
>
> Key: DRILL-4399
> URL: https://issues.apache.org/jira/browse/DRILL-4399
> Project: Apache Drill
>  Issue Type: Bug
>  Components:  Server
>Affects Versions: 1.5.0
>Reporter: N Campbell
>Assignee: Taras Supyk
>
> Doc set makes not mention of this, but parses and executes
> select 1 from postgres.public.tdt where (date '1999-12-01' , date 
> '2001-12-31' ) overlaps  ( date '2001-01-01' , tdt.cdt ) and rnum=0
> This query executed by Postgres would return 1 row
> create table TDT ( RNUM integer  not null , CDT date   ) ;
> comment on table TDT is 'This describes table TDT.';
> grant select on table TDT to public;
> insert into TDT(RNUM, CDT) values ( 0, NULL);
> insert into TDT(RNUM, CDT) values ( 1, DATE '1996-01-01');
> insert into TDT(RNUM, CDT) values ( 2, DATE '2000-01-01');
> insert into TDT(RNUM, CDT) values ( 3, DATE '2000-12-31');



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (DRILL-4409) projecting literal will result in an empty resultset

[Taras Supyk (JIRA)]

[ 
https://issues.apache.org/jira/browse/DRILL-4409?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15171711#comment-15171711
 ] 

Taras Supyk commented on DRILL-4409:


Confirmed

> projecting literal will result in an empty resultset
> 
>
> Key: DRILL-4409
> URL: https://issues.apache.org/jira/browse/DRILL-4409
> Project: Apache Drill
>  Issue Type: Bug
>  Components:  Server
>Affects Versions: 1.5.0
>Reporter: N Campbell
>Assignee: Taras Supyk
>
> A query which projects a literal as shown against a Postgres table will 
> result in an empty result set being returned. 
> select 'BB' from postgres.public.tversion



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (DRILL-4405) invalid Postgres SQL generated for CONCAT (literal, literal)

[Taras Supyk (JIRA)]

[ 
https://issues.apache.org/jira/browse/DRILL-4405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15171710#comment-15171710
 ] 

Taras Supyk commented on DRILL-4405:


Confirmed

> invalid Postgres SQL generated for CONCAT (literal, literal) 
> -
>
> Key: DRILL-4405
> URL: https://issues.apache.org/jira/browse/DRILL-4405
> Project: Apache Drill
>  Issue Type: Bug
>  Components:  Server
>Affects Versions: 1.5.0
>Reporter: N Campbell
>Assignee: Taras Supyk
>
> select concat( 'FF' , 'FF' )  from postgres.public.tversion
> Error: DATA_READ ERROR: The JDBC storage plugin failed while trying setup the 
> SQL query. 
> sql SELECT CAST('' AS ANY) AS "EXPR$0"
> FROM "public"."tversion"
> plugin postgres
> Fragment 0:0
> [Error Id: c3f24106-8d75-4a57-a638-ac5f0aca0769 on centos1:31010]
>   (org.postgresql.util.PSQLException) ERROR: syntax error at or near "ANY"
>   Position: 23
> org.postgresql.core.v3.QueryExecutorImpl.receiveErrorResponse():2182
> org.postgresql.core.v3.QueryExecutorImpl.processResults():1911
> org.postgresql.core.v3.QueryExecutorImpl.execute():173
> org.postgresql.jdbc.PgStatement.execute():622
> org.postgresql.jdbc.PgStatement.executeWithFlags():458
> org.postgresql.jdbc.PgStatement.executeQuery():374
> org.apache.commons.dbcp.DelegatingStatement.executeQuery():208
> org.apache.commons.dbcp.DelegatingStatement.executeQuery():208
> org.apache.drill.exec.store.jdbc.JdbcRecordReader.setup():177
> org.apache.drill.exec.physical.impl.ScanBatch.():108
> org.apache.drill.exec.physical.impl.ScanBatch.():136
> org.apache.drill.exec.store.jdbc.JdbcBatchCreator.getBatch():40
> org.apache.drill.exec.store.jdbc.JdbcBatchCreator.getBatch():33
> org.apache.drill.exec.physical.impl.ImplCreator.getRecordBatch():147
> org.apache.drill.exec.physical.impl.ImplCreator.getChildren():170
> org.apache.drill.exec.physical.impl.ImplCreator.getRootExec():101
> org.apache.drill.exec.physical.impl.ImplCreator.getExec():79
> org.apache.drill.exec.work.fragment.FragmentExecutor.run():230
> org.apache.drill.common.SelfCleaningRunnable.run():38
> java.util.concurrent.ThreadPoolExecutor.runWorker():1142
> java.util.concurrent.ThreadPoolExecutor$Worker.run():617
> java.lang.Thread.run():745
> SQLState:  null
> ErrorCode: 0



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (DRILL-4406) extract () Error: SYSTEM ERROR: ClassCastException. Caused By (java.lang.ClassCastException)

[Taras Supyk (JIRA)]

[ 
https://issues.apache.org/jira/browse/DRILL-4406?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15171706#comment-15171706
 ] 

Taras Supyk commented on DRILL-4406:


Confirmed, select extract(hour from cts) from public.tts; causes 
ClassCastException: org.apache.calcite.avatica.util.TimeUnitRange cannot be 
cast to org.apache.calcite.sql.SqlLiteral$SqlSymbol

> extract () Error: SYSTEM ERROR: ClassCastException. Caused By 
> (java.lang.ClassCastException) 
> -
>
> Key: DRILL-4406
> URL: https://issues.apache.org/jira/browse/DRILL-4406
> Project: Apache Drill
>  Issue Type: Bug
>  Components:  Server
>Affects Versions: 1.5.0
>Reporter: N Campbell
>Assignee: Taras Supyk
> Fix For: 1.5.0
>
>
> Trying to extract( ) from a Postgres timestamp column fails
> create table TTS ( RNUM integer  not null , CTS timestamp(3 ) ) ;
> Error: SYSTEM ERROR: ClassCastException
> [Error Id: 4a6a1f6e-1caa-42c4-b44c-8db62146 on centos1:31010]
>   (org.apache.drill.exec.work.foreman.ForemanException) Unexpected exception 
> during fragment initialization: null
> org.apache.drill.exec.work.foreman.Foreman.run():261
> java.util.concurrent.ThreadPoolExecutor.runWorker():1142
> java.util.concurrent.ThreadPoolExecutor$Worker.run():617
> java.lang.Thread.run():745
>   Caused By (java.lang.ClassCastException) null
> SQLState:  null
> ErrorCode: 0



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (DRILL-4402) pushing unsupported full outer join to Postgres

[Taras Supyk (JIRA)]

[ 
https://issues.apache.org/jira/browse/DRILL-4402?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15171698#comment-15171698
 ] 

Taras Supyk commented on DRILL-4402:


Confirmed

> pushing unsupported full outer join to Postgres
> ---
>
> Key: DRILL-4402
> URL: https://issues.apache.org/jira/browse/DRILL-4402
> Project: Apache Drill
>  Issue Type: Bug
>  Components:  Server
>Affects Versions: 1.5.0
>Reporter: N Campbell
>Assignee: Taras Supyk
>
> Error: DATA_READ ERROR: The JDBC storage plugin failed while trying setup the 
> SQL query. 
> sql SELECT *
> FROM "public"."tjoin1"
> FULL JOIN "public"."tjoin2" ON "tjoin1"."c1" < "tjoin2"."c1"
> plugin postgres
> Fragment 0:0
> [Error Id: bc54cf76-f4ff-474c-b3df-fa357bdf0ff8 on centos1:31010]
>   (org.postgresql.util.PSQLException) ERROR: FULL JOIN is only supported with 
> merge-joinable or hash-joinable join conditions
> org.postgresql.core.v3.QueryExecutorImpl.receiveErrorResponse():2182
> org.postgresql.core.v3.QueryExecutorImpl.processResults():1911
> org.postgresql.core.v3.QueryExecutorImpl.execute():173
> org.postgresql.jdbc.PgStatement.execute():622
> org.postgresql.jdbc.PgStatement.executeWithFlags():458
> org.postgresql.jdbc.PgStatement.executeQuery():374
> org.apache.commons.dbcp.DelegatingStatement.executeQuery():208
> org.apache.commons.dbcp.DelegatingStatement.executeQuery():208
> org.apache.drill.exec.store.jdbc.JdbcRecordReader.setup():177
> org.apache.drill.exec.physical.impl.ScanBatch.():108
> org.apache.drill.exec.physical.impl.ScanBatch.():136
> org.apache.drill.exec.store.jdbc.JdbcBatchCreator.getBatch():40
> org.apache.drill.exec.store.jdbc.JdbcBatchCreator.getBatch():33
> org.apache.drill.exec.physical.impl.ImplCreator.getRecordBatch():147
> org.apache.drill.exec.physical.impl.ImplCreator.getChildren():170
> org.apache.drill.exec.physical.impl.ImplCreator.getRecordBatch():127
> org.apache.drill.exec.physical.impl.ImplCreator.getChildren():170
> org.apache.drill.exec.physical.impl.ImplCreator.getRecordBatch():127
> org.apache.drill.exec.physical.impl.ImplCreator.getChildren():170
> org.apache.drill.exec.physical.impl.ImplCreator.getRootExec():101
> org.apache.drill.exec.physical.impl.ImplCreator.getExec():79
> org.apache.drill.exec.work.fragment.FragmentExecutor.run():230
> org.apache.drill.common.SelfCleaningRunnable.run():38
> java.util.concurrent.ThreadPoolExecutor.runWorker():1142
> java.util.concurrent.ThreadPoolExecutor$Worker.run():617
> java.lang.Thread.run():745
> SQLState:  null
> ErrorCode: 0
> create table TJOIN1 (RNUM integer   not null , C1 integer, C2 integer);
> insert into TJOIN1 (RNUM, C1, C2) values ( 0, 10, 15);
> insert into TJOIN1 (RNUM, C1, C2) values ( 1, 20, 25);
> insert into TJOIN1 (RNUM, C1, C2) values ( 2, NULL, 50);
> create table TJOIN2 (RNUM integer   not null , C1 integer, C2 char(2));
> insert into TJOIN2 (RNUM, C1, C2) values ( 0, 10, 'BB');
> insert into TJOIN2 (RNUM, C1, C2) values ( 1, 15, 'DD');
> insert into TJOIN2 (RNUM, C1, C2) values ( 2, NULL, 'EE');
> insert into TJOIN2 (RNUM, C1, C2) values ( 3, 10, 'FF');



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (DRILL-4391) browsing metadata via SQLSquirrel shows Postgres indexes, primary and foreign keys as tables

[Taras Supyk (JIRA)]

[ 
https://issues.apache.org/jira/browse/DRILL-4391?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15171691#comment-15171691
 ] 

Taras Supyk commented on DRILL-4391:


Reproduce steps:

create sequence user_ids;
create table users (id integer primary key default nextval('user_ids'), login 
char(64);

In drill console:

show tables in psql.public;

user_ids and users_pkey are also shown in result as tables 

> browsing metadata via SQLSquirrel shows Postgres indexes, primary and foreign 
> keys as tables
> 
>
> Key: DRILL-4391
> URL: https://issues.apache.org/jira/browse/DRILL-4391
> Project: Apache Drill
>  Issue Type: Bug
>  Components: Metadata
>Affects Versions: 1.4.0
>Reporter: N Campbell
>Assignee: Taras Supyk
>
> Apache Drill has storage defined to access a Postgres database 
> A schema in the database has several tables which either have indexes, 
> primary keys, foreign keys or combination of them all. 
> When SQLSquirrel presents metadata from the Drill JDBC driver the list of 
> tables will include entries which correspond to the indexes, primary or 
> foreign keys in the schema. The implication being that non-standard JDBC 
> metadata methods to obtain information is being used.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (DRILL-4391) browsing metadata via SQLSquirrel shows Postgres indexes, primary and foreign keys as tables

[Taras Supyk (JIRA)]

[ 
https://issues.apache.org/jira/browse/DRILL-4391?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15171677#comment-15171677
 ] 

Taras Supyk commented on DRILL-4391:


Confirmed

> browsing metadata via SQLSquirrel shows Postgres indexes, primary and foreign 
> keys as tables
> 
>
> Key: DRILL-4391
> URL: https://issues.apache.org/jira/browse/DRILL-4391
> Project: Apache Drill
>  Issue Type: Bug
>  Components: Metadata
>Affects Versions: 1.4.0
>Reporter: N Campbell
>Assignee: Taras Supyk
>
> Apache Drill has storage defined to access a Postgres database 
> A schema in the database has several tables which either have indexes, 
> primary keys, foreign keys or combination of them all. 
> When SQLSquirrel presents metadata from the Drill JDBC driver the list of 
> tables will include entries which correspond to the indexes, primary or 
> foreign keys in the schema. The implication being that non-standard JDBC 
> metadata methods to obtain information is being used.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Comment Edited] (DRILL-4391) browsing metadata via SQLSquirrel shows Postgres indexes, primary and foreign keys as tables

[Taras Supyk (JIRA)]

[ 
https://issues.apache.org/jira/browse/DRILL-4391?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15171677#comment-15171677
 ] 

Taras Supyk edited comment on DRILL-4391 at 2/29/16 10:03 AM:
--

Confirmed in Drill 1.4 and 1.5


was (Author: dr-wolf):
Confirmed

> browsing metadata via SQLSquirrel shows Postgres indexes, primary and foreign 
> keys as tables
> 
>
> Key: DRILL-4391
> URL: https://issues.apache.org/jira/browse/DRILL-4391
> Project: Apache Drill
>  Issue Type: Bug
>  Components: Metadata
>Affects Versions: 1.4.0
>Reporter: N Campbell
>Assignee: Taras Supyk
>
> Apache Drill has storage defined to access a Postgres database 
> A schema in the database has several tables which either have indexes, 
> primary keys, foreign keys or combination of them all. 
> When SQLSquirrel presents metadata from the Drill JDBC driver the list of 
> tables will include entries which correspond to the indexes, primary or 
> foreign keys in the schema. The implication being that non-standard JDBC 
> metadata methods to obtain information is being used.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (DRILL-2805) Throw clear error message when maxdir/mindir UDFs are used in any other part of SQL, but where clause

[Arina Ielchiieva (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DRILL-2805?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Arina Ielchiieva closed DRILL-2805.
---
Resolution: Fixed
  Assignee: Arina Ielchiieva

Fixed in cca17cb in sope of DRILL-3944

> Throw clear error message when maxdir/mindir UDFs are used in any other part 
> of SQL, but where clause
> -
>
> Key: DRILL-2805
> URL: https://issues.apache.org/jira/browse/DRILL-2805
> Project: Apache Drill
>  Issue Type: Bug
>  Components: Functions - Drill
>Affects Versions: 0.9.0
>Reporter: Victoria Markman
>Assignee: Arina Ielchiieva
> Fix For: Future
>
>
> This  error message is not right. I think the problem here is that we are not 
> allowing to use these UDFs in projection list, group by or order by.
> Can we please have an error message that says that ?
> {code}
> 0: jdbc:drill:schema=dfs> select maxdir('dfs.test', 'bigtable') from 
> smalltable  group by maxdir('dfs.test', 'bigtable');
> Query failed: SYSTEM ERROR: The partition explorer interface can only be used 
> in functions that can be evaluated at planning time. Make sure that the 
> planner.enable_constant_folding configuration option is set to true.
> [6c9dd988-0960-4a3a-9495-535e245f0daa on atsqa4-134.qa.lab:31010]
> Error: exception while executing query: Failure while executing query. 
> (state=,code=0)
> {code}
> This is the correct way this error message is used:
> {code}
> 0: jdbc:drill:schema=dfs> select * from smalltable where dir0 = 
> maxdir('dfs.test', 'bigtable') and dir1 = mindir('dfs.test', 'bigtable/2016');
> ++++
> |  columns   |dir0|dir1|
> ++++
> ++++
> No rows selected (0.943 seconds)
> 0: jdbc:drill:schema=dfs> alter session set `planner.enable_constant_folding` 
> = false;
> +++
> | ok |  summary   |
> +++
> | true   | planner.enable_constant_folding updated. |
> +++
> 1 row selected (0.108 seconds)
> 0: jdbc:drill:schema=dfs> select * from smalltable where dir0 = 
> maxdir('dfs.test', 'bigtable') and dir1 = mindir('dfs.test', 'bigtable/2016');
> Query failed: SYSTEM ERROR: The partition explorer interface can only be used 
> in functions that can be evaluated at planning time. Make sure that the 
> planner.enable_constant_folding configuration option is set to true.
> [c22bad01-f9c7-43ba-b76c-8a11be518b40 on atsqa4-134.qa.lab:31010]
> Error: exception while executing query: Failure while executing query. 
> (state=,code=0)
> {code}
> Btw, I'm not sure I understand why we want to make constant folding 
> configurable. Is the any benefit to not have it turned on ?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)