[JBoss JIRA] (TEIID-3568) Order By and Limit are not getting pushed to the database, when Union and join are used together.
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-3568?page=com.atlassian.jira.plugin... ]
Steven Hawkins commented on TEIID-3568:
---------------------------------------
If they are to the same DB2 source, I would expect everything to push down as there is nothing obviously inhibiting that and I see full pushdown locally with a similar scenario. Can you provide the debug plan from "set showplan debug" from 8.7?
> Order By and Limit are not getting pushed to the database, when Union and join are used together.
> --------------------------------------------------------------------------------------------------
>
> Key: TEIID-3568
> URL: https://issues.jboss.org/browse/TEIID-3568
> Project: Teiid
> Issue Type: Bug
> Affects Versions: 8.1
> Reporter: Guru Prasad
> Assignee: Steven Hawkins
>
> Order By and Limit are not getting pushed to the database, when Union and join are used together.
> In this scenario there if the underlying table has millions of records the query never returns with data.
> *Query 1*: Using only Join without union, this works fine.
> SELECT u.evttypecode, u.evtsysid, u.evtutctod, u.evtsystod, u.evtcatcode FROM (
> select evttypecode, evtsysid, evtutctod, evtsystod, evtcatcode from XYZ.Tab1
> ) as u
> LEFT OUTER JOIN XYZ.CATEGORY AS ct ON u.evtcatcode = ct.evtcatcode
> WHERE (u.EVTUTCTOD >= {ts'2015-06-03 19:20:00.8'}) AND (u.EVTUTCTOD <= {ts'2015-06-03 19:20:01.0'}) ORDER BY u.evtsysid LIMIT 8
> PROCESSOR PLAN:
> AccessNode(0) output=[evttypecode AS evttypecode, evtsysid AS evtsysid, evtutctod AS evtutctod, evtsystod AS evtsystod, evtcatcode AS evtcatcode]
> SELECT g_0.EVTTYPECODE AS c_0, g_0.EVTSYSID AS c_1, g_0.EVTUTCTOD AS c_2, g_0.EVTSYSTOD AS c_3, g_0.EVTCATCODE AS c_4 FROM ABC.Tab1 AS g_0 LEFT OUTER JOIN ABC.CATEGORY AS g_1 ON g_0.EVTCATCODE = g_1.EVTCATCODE WHERE (g_0.EVTUTCTOD >= {ts'2015-06-03 19:20:00.8'}) AND (g_0.EVTUTCTOD <= {ts'2015-06-03 19:20:01.0'}) ORDER BY c_1 LIMIT 8
> *Query 2*: Using only Union without any join, this also works fine.
> SELECT u.evttypecode, u.evtsysid, u.evtutctod, u.evtsystod, u.evtcatcode FROM (
> select evttypecode, evtsysid, evtutctod, evtsystod, evtcatcode from XYZ.Tab1
> UNION ALL
> select evttypecode, evtsysid, evtutctod, evtsystod, evtcatcode from XYZ.Tab2
> ) as u
> WHERE (u.EVTUTCTOD >= {ts'2015-06-03 19:20:00.8'}) AND (u.EVTUTCTOD <= {ts'2015-06-03 19:20:01.0'}) ORDER BY u.evtsysid LIMIT 8
> PROCESSOR PLAN:
> AccessNode(0) output=[evttypecode AS evttypecode, evtsysid AS evtsysid, evtutctod AS evtutctod, evtsystod AS evtsystod, evtcatcode AS evtcatcode]
> SELECT g_1.EVTTYPECODE AS c_0, g_1.EVTSYSID AS c_1, g_1.EVTUTCTOD AS c_2, g_1.EVTSYSTOD AS c_3, g_1.EVTCATCODE AS c_4 FROM ABC.Tab1 AS g_1 WHERE (g_1.EVTUTCTOD >= {ts'2015-06-03 19:20:00.8'}) AND (g_1.EVTUTCTOD <= {ts'2015-06-03 19:20:01.0'}) UNION ALL
> SELECT g_0.EVTTYPECODE AS c_0, g_0.EVTSYSID AS c_1, g_0.EVTUTCTOD AS c_2, g_0.EVTSYSTOD AS c_3, g_0.EVTCATCODE AS c_4 FROM ABC.Tab2 AS g_0 WHERE (g_0.EVTUTCTOD >= {ts'2015-06-03 19:20:00.8'}) AND (g_0.EVTUTCTOD <= {ts'2015-06-03 19:20:01.0'}) ORDER BY c_1 LIMIT 8
> *Query 3*: Using both Union and join, this does not push down the order by and limit.
> SELECT u.evttypecode, u.evtsysid, u.evtutctod, u.evtsystod, u.evtcatcode FROM (
> select evttypecode, evtsysid, evtutctod, evtsystod, evtcatcode from XYZ.Tab1
> UNION ALL
> select evttypecode, evtsysid, evtutctod, evtsystod, evtcatcode from XYZ.Tab2
> ) as u
> LEFT OUTER JOIN XYZ.EVTTYPE AS tp ON tp.evttypecode = u.evttypecode
> LEFT OUTER JOIN XYZ.CATEGORY AS ct ON u.evtcatcode = ct.evtcatcode
> WHERE (u.EVTUTCTOD >= {ts'2015-06-03 19:20:00.8'}) AND (u.EVTUTCTOD <= {ts'2015-06-03 19:20:01.0'}) ORDER BY u.evtsysid LIMIT 8
> PROCESSOR PLAN:
> ProjectNode(0) output=[u.evttypecode, u.evtsysid, u.evtutctod, u.evtsystod, u.evtcatcode] [u.evttypecode, u.evtsysid, u.evtutctod, u.evtsystod, u.evtcatcode]
> LimitNode(1) output=[u.evttypecode, u.evtsysid, u.evtutctod, u.evtsystod, u.evtcatcode] limit 8
> SortNode(2) output=[u.evttypecode, u.evtsysid, u.evtutctod, u.evtsystod, u.evtcatcode] [SORT] [u.evtsysid]
> JoinNode(3) [MERGE JOIN (SORT/ALREADY_SORTED)] [LEFT OUTER JOIN] criteria=[u.evtcatcode=evtcatcode] output=[u.evttypecode, u.evtsysid, u.evtutctod, u.evtsystod, u.evtcatcode]
> JoinNode(4) [MERGE JOIN (SORT/ALREADY_SORTED)] [LEFT OUTER JOIN] criteria=[u.evttypecode=evttypecode] output=[u.evtcatcode, u.evttypecode, u.evtsysid, u.evtutctod, u.evtsystod]
> AccessNode(5) output=[u.evttypecode, u.evtcatcode, u.evtsysid, u.evtutctod, u.evtsystod]
> SELECT g_1.EVTTYPECODE AS c_0, g_1.EVTCATCODE AS c_1, g_1.EVTSYSID AS c_2, g_1.EVTUTCTOD AS c_3, g_1.EVTSYSTOD AS c_4 FROM ABC.Tab1 AS g_1 WHERE (g_1.EVTUTCTOD >= {ts'2015-06-03 19:20:00.8'}) AND (g_1.EVTUTCTOD <= {ts'2015-06-03 19:20:01.0'})
> UNION ALL SELECT g_0.EVTTYPECODE AS c_0, g_0.EVTCATCODE AS c_1, g_0.EVTSYSID AS c_2, g_0.EVTUTCTOD AS c_3, g_0.EVTSYSTOD AS c_4 FROM ABC.Tab2 AS g_0 WHERE (g_0.EVTUTCTOD >= {ts'2015-06-03 19:20:00.8'}) AND (g_0.EVTUTCTOD <= {ts'2015-06-03 19:20:01.0'})
> AccessNode(6) output=[evttypecode] SELECT g_0.EVTTYPECODE AS c_0 FROM ABC.EVTTYPE AS g_0 ORDER BY c_0
> AccessNode(7) output=[evtcatcode] SELECT g_0.EVTCATCODE AS c_0 FROM ABC.CATEGORY AS g_0 ORDER BY c_0
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
9 years, 6 months
[JBoss JIRA] (TEIID-3568) Order By and Limit are not getting pushed to the database, when Union and join are used together.
by Guru Prasad (JIRA)
[ https://issues.jboss.org/browse/TEIID-3568?page=com.atlassian.jira.plugin... ]
Guru Prasad commented on TEIID-3568:
------------------------------------
Here evttype, category, tab1 and tab2 are actually views which in turn connect to the same data source.
Yes, I was checking if ordered limit can be pushed to the left outer join as tab1/tab2 have huge number of records.
> Order By and Limit are not getting pushed to the database, when Union and join are used together.
> --------------------------------------------------------------------------------------------------
>
> Key: TEIID-3568
> URL: https://issues.jboss.org/browse/TEIID-3568
> Project: Teiid
> Issue Type: Bug
> Affects Versions: 8.1
> Reporter: Guru Prasad
> Assignee: Steven Hawkins
>
> Order By and Limit are not getting pushed to the database, when Union and join are used together.
> In this scenario there if the underlying table has millions of records the query never returns with data.
> *Query 1*: Using only Join without union, this works fine.
> SELECT u.evttypecode, u.evtsysid, u.evtutctod, u.evtsystod, u.evtcatcode FROM (
> select evttypecode, evtsysid, evtutctod, evtsystod, evtcatcode from XYZ.Tab1
> ) as u
> LEFT OUTER JOIN XYZ.CATEGORY AS ct ON u.evtcatcode = ct.evtcatcode
> WHERE (u.EVTUTCTOD >= {ts'2015-06-03 19:20:00.8'}) AND (u.EVTUTCTOD <= {ts'2015-06-03 19:20:01.0'}) ORDER BY u.evtsysid LIMIT 8
> PROCESSOR PLAN:
> AccessNode(0) output=[evttypecode AS evttypecode, evtsysid AS evtsysid, evtutctod AS evtutctod, evtsystod AS evtsystod, evtcatcode AS evtcatcode]
> SELECT g_0.EVTTYPECODE AS c_0, g_0.EVTSYSID AS c_1, g_0.EVTUTCTOD AS c_2, g_0.EVTSYSTOD AS c_3, g_0.EVTCATCODE AS c_4 FROM ABC.Tab1 AS g_0 LEFT OUTER JOIN ABC.CATEGORY AS g_1 ON g_0.EVTCATCODE = g_1.EVTCATCODE WHERE (g_0.EVTUTCTOD >= {ts'2015-06-03 19:20:00.8'}) AND (g_0.EVTUTCTOD <= {ts'2015-06-03 19:20:01.0'}) ORDER BY c_1 LIMIT 8
> *Query 2*: Using only Union without any join, this also works fine.
> SELECT u.evttypecode, u.evtsysid, u.evtutctod, u.evtsystod, u.evtcatcode FROM (
> select evttypecode, evtsysid, evtutctod, evtsystod, evtcatcode from XYZ.Tab1
> UNION ALL
> select evttypecode, evtsysid, evtutctod, evtsystod, evtcatcode from XYZ.Tab2
> ) as u
> WHERE (u.EVTUTCTOD >= {ts'2015-06-03 19:20:00.8'}) AND (u.EVTUTCTOD <= {ts'2015-06-03 19:20:01.0'}) ORDER BY u.evtsysid LIMIT 8
> PROCESSOR PLAN:
> AccessNode(0) output=[evttypecode AS evttypecode, evtsysid AS evtsysid, evtutctod AS evtutctod, evtsystod AS evtsystod, evtcatcode AS evtcatcode]
> SELECT g_1.EVTTYPECODE AS c_0, g_1.EVTSYSID AS c_1, g_1.EVTUTCTOD AS c_2, g_1.EVTSYSTOD AS c_3, g_1.EVTCATCODE AS c_4 FROM ABC.Tab1 AS g_1 WHERE (g_1.EVTUTCTOD >= {ts'2015-06-03 19:20:00.8'}) AND (g_1.EVTUTCTOD <= {ts'2015-06-03 19:20:01.0'}) UNION ALL
> SELECT g_0.EVTTYPECODE AS c_0, g_0.EVTSYSID AS c_1, g_0.EVTUTCTOD AS c_2, g_0.EVTSYSTOD AS c_3, g_0.EVTCATCODE AS c_4 FROM ABC.Tab2 AS g_0 WHERE (g_0.EVTUTCTOD >= {ts'2015-06-03 19:20:00.8'}) AND (g_0.EVTUTCTOD <= {ts'2015-06-03 19:20:01.0'}) ORDER BY c_1 LIMIT 8
> *Query 3*: Using both Union and join, this does not push down the order by and limit.
> SELECT u.evttypecode, u.evtsysid, u.evtutctod, u.evtsystod, u.evtcatcode FROM (
> select evttypecode, evtsysid, evtutctod, evtsystod, evtcatcode from XYZ.Tab1
> UNION ALL
> select evttypecode, evtsysid, evtutctod, evtsystod, evtcatcode from XYZ.Tab2
> ) as u
> LEFT OUTER JOIN XYZ.EVTTYPE AS tp ON tp.evttypecode = u.evttypecode
> LEFT OUTER JOIN XYZ.CATEGORY AS ct ON u.evtcatcode = ct.evtcatcode
> WHERE (u.EVTUTCTOD >= {ts'2015-06-03 19:20:00.8'}) AND (u.EVTUTCTOD <= {ts'2015-06-03 19:20:01.0'}) ORDER BY u.evtsysid LIMIT 8
> PROCESSOR PLAN:
> ProjectNode(0) output=[u.evttypecode, u.evtsysid, u.evtutctod, u.evtsystod, u.evtcatcode] [u.evttypecode, u.evtsysid, u.evtutctod, u.evtsystod, u.evtcatcode]
> LimitNode(1) output=[u.evttypecode, u.evtsysid, u.evtutctod, u.evtsystod, u.evtcatcode] limit 8
> SortNode(2) output=[u.evttypecode, u.evtsysid, u.evtutctod, u.evtsystod, u.evtcatcode] [SORT] [u.evtsysid]
> JoinNode(3) [MERGE JOIN (SORT/ALREADY_SORTED)] [LEFT OUTER JOIN] criteria=[u.evtcatcode=evtcatcode] output=[u.evttypecode, u.evtsysid, u.evtutctod, u.evtsystod, u.evtcatcode]
> JoinNode(4) [MERGE JOIN (SORT/ALREADY_SORTED)] [LEFT OUTER JOIN] criteria=[u.evttypecode=evttypecode] output=[u.evtcatcode, u.evttypecode, u.evtsysid, u.evtutctod, u.evtsystod]
> AccessNode(5) output=[u.evttypecode, u.evtcatcode, u.evtsysid, u.evtutctod, u.evtsystod]
> SELECT g_1.EVTTYPECODE AS c_0, g_1.EVTCATCODE AS c_1, g_1.EVTSYSID AS c_2, g_1.EVTUTCTOD AS c_3, g_1.EVTSYSTOD AS c_4 FROM ABC.Tab1 AS g_1 WHERE (g_1.EVTUTCTOD >= {ts'2015-06-03 19:20:00.8'}) AND (g_1.EVTUTCTOD <= {ts'2015-06-03 19:20:01.0'})
> UNION ALL SELECT g_0.EVTTYPECODE AS c_0, g_0.EVTCATCODE AS c_1, g_0.EVTSYSID AS c_2, g_0.EVTUTCTOD AS c_3, g_0.EVTSYSTOD AS c_4 FROM ABC.Tab2 AS g_0 WHERE (g_0.EVTUTCTOD >= {ts'2015-06-03 19:20:00.8'}) AND (g_0.EVTUTCTOD <= {ts'2015-06-03 19:20:01.0'})
> AccessNode(6) output=[evttypecode] SELECT g_0.EVTTYPECODE AS c_0 FROM ABC.EVTTYPE AS g_0 ORDER BY c_0
> AccessNode(7) output=[evtcatcode] SELECT g_0.EVTCATCODE AS c_0 FROM ABC.CATEGORY AS g_0 ORDER BY c_0
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
9 years, 6 months
[JBoss JIRA] (TEIID-3574) Teiid ODBC driver inconsistent error logs
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/TEIID-3574?page=com.atlassian.jira.plugin... ]
RH Bugzilla Integration updated TEIID-3574:
-------------------------------------------
Bugzilla Update: Perform
Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1243466
> Teiid ODBC driver inconsistent error logs
> -----------------------------------------
>
> Key: TEIID-3574
> URL: https://issues.jboss.org/browse/TEIID-3574
> Project: Teiid
> Issue Type: Bug
> Components: Query Engine
> Affects Versions: 8.7.1.6_2
> Reporter: Jan Stastny
> Assignee: Steven Hawkins
> Labels: odbc
>
> When comparing behaviour of ODBC driver with behaviour of JDBC driver there are a few inconsistencies.
> For particular malformed query there is:
> # no error log entry for ODBC driver, while for JDBC there is a comprehensive explanation in the server logs.
> #* Example query:
> {code:sql}
> SELECT title, COUNT() FROM employeefixed
> {code}
> #* JDBC log entry:
> {code:plain}WARN [org.teiid.PROCESSOR] (Worker13_QueryProcessorQueue382) TEIID30020 Processing exception for request pIU27iFFv21F.7 'TEIID31100 Parsing error: Encountered ", COUNT([*])[*] FROM employeefixed" at line 1, column 21.
> Was expecting: "char" | "cast" | "convert" | "all" | "any" | "array_agg" | "case" | "distinct" | "exists" | "false" ...'. Originally QueryParserException QueryParser.java:214. Enable more detailed logging to see the entire stacktrace.
> {code}
> #* ODBC log entry:
> none present
> # error log but also exception stack trace
> #* Example query:
> {code:sql}
> SELECT title, city, COUNT(title) FROM employeefixed GROUP BY title
> {code}
> #* JDBC log entry:
> {code:plain}
> WARN [org.teiid.PROCESSOR] (Worker14_QueryProcessorQueue384) TEIID30020 Processing exception for request pIU27iFFv21F.8 'TEIID30492 [EmployeeFixedData.EmployeeFixed.city] cannot be used outside of aggregate functions since they are not present in a GROUP BY clause.'. Originally QueryValidatorException Request.java:305. Enable more detailed logging to see the entire stacktrace.
> {code}
> #* ODBC log entry:
> {code:plain}
> WARN [org.teiid.PROCESSOR] (Worker14_QueryProcessorQueue383) TEIID30020 Processing exception for request RPpTChkE/84O.40 'TEIID30492 [EmployeeFixedData.EmployeeFixed.city] cannot be used outside of aggregate functions since they are not present in a GROUP BY clause.'. Originally QueryValidatorException Request.java:305. Enable more detailed logging to see the entire stacktrace.
> ERROR [org.teiid.ODBC] (Worker14_QueryProcessorQueue383) TEIID40015 Unexpected error occurred: java.util.concurrent.ExecutionException: org.teiid.jdbc.TeiidSQLException: TEIID30492 [EmployeeFixedData.EmployeeFixed.city] cannot be used outside of aggregate functions since they are not present in a GROUP BY clause.
> at org.teiid.client.util.ResultsFuture.convertResult(ResultsFuture.java:104) [teiid-client-8.7.1.6_2-redhat-3.jar:8.7.1.6_2-redhat-3]
> at org.teiid.client.util.ResultsFuture.get(ResultsFuture.java:99) [teiid-client-8.7.1.6_2-redhat-3.jar:8.7.1.6_2-redhat-3]
> at org.teiid.odbc.ODBCServerRemoteImpl$5.onCompletion(ODBCServerRemoteImpl.java:586) [teiid-runtime-8.7.1.6_2-redhat-3.jar:8.7.1.6_2-redhat-3]
> at org.teiid.client.util.ResultsFuture.done(ResultsFuture.java:135) [teiid-client-8.7.1.6_2-redhat-3.jar:8.7.1.6_2-redhat-3]
> at org.teiid.client.util.ResultsFuture.access$200(ResultsFuture.java:40) [teiid-client-8.7.1.6_2-redhat-3.jar:8.7.1.6_2-redhat-3]
> at org.teiid.client.util.ResultsFuture$1.exceptionOccurred(ResultsFuture.java:68) [teiid-client-8.7.1.6_2-redhat-3.jar:8.7.1.6_2-redhat-3]
> at org.teiid.jdbc.StatementImpl$2.onCompletion(StatementImpl.java:518) [teiid-client-8.7.1.6_2-redhat-3.jar:8.7.1.6_2-redhat-3]
> at org.teiid.client.util.ResultsFuture.done(ResultsFuture.java:135) [teiid-client-8.7.1.6_2-redhat-3.jar:8.7.1.6_2-redhat-3]
> at org.teiid.client.util.ResultsFuture.access$200(ResultsFuture.java:40) [teiid-client-8.7.1.6_2-redhat-3.jar:8.7.1.6_2-redhat-3]
> at org.teiid.client.util.ResultsFuture$1.receiveResults(ResultsFuture.java:79) [teiid-client-8.7.1.6_2-redhat-3.jar:8.7.1.6_2-redhat-3]
> at org.teiid.dqp.internal.process.RequestWorkItem.sendError(RequestWorkItem.java:1001) [teiid-engine-8.7.1.6_2-redhat-3.jar:8.7.1.6_2-redhat-3]
> at org.teiid.dqp.internal.process.RequestWorkItem.close(RequestWorkItem.java:556) [teiid-engine-8.7.1.6_2-redhat-3.jar:8.7.1.6_2-redhat-3]
> at org.teiid.dqp.internal.process.RequestWorkItem.process(RequestWorkItem.java:352) [teiid-engine-8.7.1.6_2-redhat-3.jar:8.7.1.6_2-redhat-3]
> at org.teiid.dqp.internal.process.AbstractWorkItem.run(AbstractWorkItem.java:51) [teiid-engine-8.7.1.6_2-redhat-3.jar:8.7.1.6_2-redhat-3]
> at org.teiid.dqp.internal.process.RequestWorkItem.run(RequestWorkItem.java:254) [teiid-engine-8.7.1.6_2-redhat-3.jar:8.7.1.6_2-redhat-3]
> at org.teiid.dqp.internal.process.DQPWorkContext.runInContext(DQPWorkContext.java:274) [teiid-engine-8.7.1.6_2-redhat-3.jar:8.7.1.6_2-redhat-3]
> at org.teiid.dqp.internal.process.ThreadReuseExecutor$RunnableWrapper.run(ThreadReuseExecutor.java:119) [teiid-engine-8.7.1.6_2-redhat-3.jar:8.7.1.6_2-redhat-3]
> at org.teiid.dqp.internal.process.ThreadReuseExecutor$3.run(ThreadReuseExecutor.java:210) [teiid-engine-8.7.1.6_2-redhat-3.jar:8.7.1.6_2-redhat-3]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_75]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_75]
> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.7.0_75]
> Caused by: org.teiid.jdbc.TeiidSQLException: TEIID30492 [EmployeeFixedData.EmployeeFixed.city] cannot be used outside of aggregate functions since they are not present in a GROUP BY clause.
> at org.teiid.jdbc.TeiidSQLException.create(TeiidSQLException.java:135) [teiid-client-8.7.1.6_2-redhat-3.jar:8.7.1.6_2-redhat-3]
> at org.teiid.jdbc.TeiidSQLException.create(TeiidSQLException.java:71) [teiid-client-8.7.1.6_2-redhat-3.jar:8.7.1.6_2-redhat-3]
> at org.teiid.jdbc.StatementImpl.postReceiveResults(StatementImpl.java:667) [teiid-client-8.7.1.6_2-redhat-3.jar:8.7.1.6_2-redhat-3]
> at org.teiid.jdbc.StatementImpl.access$100(StatementImpl.java:63) [teiid-client-8.7.1.6_2-redhat-3.jar:8.7.1.6_2-redhat-3]
> at org.teiid.jdbc.StatementImpl$2.onCompletion(StatementImpl.java:515) [teiid-client-8.7.1.6_2-redhat-3.jar:8.7.1.6_2-redhat-3]
> ... 14 more
> Caused by: org.teiid.api.exception.query.QueryValidatorException: TEIID30492 [EmployeeFixedData.EmployeeFixed.city] cannot be used outside of aggregate functions since they are not present in a GROUP BY clause.
> at org.teiid.dqp.internal.process.Request.validateWithVisitor(Request.java:305) [teiid-engine-8.7.1.6_2-redhat-3.jar:8.7.1.6_2-redhat-3]
> at org.teiid.dqp.internal.process.Request.validateQuery(Request.java:268) [teiid-engine-8.7.1.6_2-redhat-3.jar:8.7.1.6_2-redhat-3]
> at org.teiid.dqp.internal.process.Request.generatePlan(Request.java:385) [teiid-engine-8.7.1.6_2-redhat-3.jar:8.7.1.6_2-redhat-3]
> at org.teiid.dqp.internal.process.PreparedStatementRequest.generatePlan(PreparedStatementRequest.java:115) [teiid-engine-8.7.1.6_2-redhat-3.jar:8.7.1.6_2-redhat-3]
> at org.teiid.dqp.internal.process.Request.processRequest(Request.java:435) [teiid-engine-8.7.1.6_2-redhat-3.jar:8.7.1.6_2-redhat-3]
> at org.teiid.dqp.internal.process.PreparedStatementRequest.processRequest(PreparedStatementRequest.java:290) [teiid-engine-8.7.1.6_2-redhat-3.jar:8.7.1.6_2-redhat-3]
> at org.teiid.dqp.internal.process.RequestWorkItem.processNew(RequestWorkItem.java:613) [teiid-engine-8.7.1.6_2-redhat-3.jar:8.7.1.6_2-redhat-3]
> at org.teiid.dqp.internal.process.RequestWorkItem.process(RequestWorkItem.java:315) [teiid-engine-8.7.1.6_2-redhat-3.jar:8.7.1.6_2-redhat-3]
> ... 8 more
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
9 years, 6 months
[JBoss JIRA] (TEIID-3574) Teiid ODBC driver inconsistent error logs
by Jan Stastny (JIRA)
Jan Stastny created TEIID-3574:
----------------------------------
Summary: Teiid ODBC driver inconsistent error logs
Key: TEIID-3574
URL: https://issues.jboss.org/browse/TEIID-3574
Project: Teiid
Issue Type: Bug
Components: Query Engine
Affects Versions: 8.7.1.6_2
Reporter: Jan Stastny
Assignee: Steven Hawkins
When comparing behaviour of ODBC driver with behaviour of JDBC driver there are a few inconsistencies.
For particular malformed query there is:
# no error log entry for ODBC driver, while for JDBC there is a comprehensive explanation in the server logs.
#* Example query:
{code:sql}
SELECT title, COUNT() FROM employeefixed
{code}
#* JDBC log entry:
{code:plain}WARN [org.teiid.PROCESSOR] (Worker13_QueryProcessorQueue382) TEIID30020 Processing exception for request pIU27iFFv21F.7 'TEIID31100 Parsing error: Encountered ", COUNT([*])[*] FROM employeefixed" at line 1, column 21.
Was expecting: "char" | "cast" | "convert" | "all" | "any" | "array_agg" | "case" | "distinct" | "exists" | "false" ...'. Originally QueryParserException QueryParser.java:214. Enable more detailed logging to see the entire stacktrace.
{code}
#* ODBC log entry:
none present
# error log but also exception stack trace
#* Example query:
{code:sql}
SELECT title, city, COUNT(title) FROM employeefixed GROUP BY title
{code}
#* JDBC log entry:
{code:plain}
WARN [org.teiid.PROCESSOR] (Worker14_QueryProcessorQueue384) TEIID30020 Processing exception for request pIU27iFFv21F.8 'TEIID30492 [EmployeeFixedData.EmployeeFixed.city] cannot be used outside of aggregate functions since they are not present in a GROUP BY clause.'. Originally QueryValidatorException Request.java:305. Enable more detailed logging to see the entire stacktrace.
{code}
#* ODBC log entry:
{code:plain}
WARN [org.teiid.PROCESSOR] (Worker14_QueryProcessorQueue383) TEIID30020 Processing exception for request RPpTChkE/84O.40 'TEIID30492 [EmployeeFixedData.EmployeeFixed.city] cannot be used outside of aggregate functions since they are not present in a GROUP BY clause.'. Originally QueryValidatorException Request.java:305. Enable more detailed logging to see the entire stacktrace.
ERROR [org.teiid.ODBC] (Worker14_QueryProcessorQueue383) TEIID40015 Unexpected error occurred: java.util.concurrent.ExecutionException: org.teiid.jdbc.TeiidSQLException: TEIID30492 [EmployeeFixedData.EmployeeFixed.city] cannot be used outside of aggregate functions since they are not present in a GROUP BY clause.
at org.teiid.client.util.ResultsFuture.convertResult(ResultsFuture.java:104) [teiid-client-8.7.1.6_2-redhat-3.jar:8.7.1.6_2-redhat-3]
at org.teiid.client.util.ResultsFuture.get(ResultsFuture.java:99) [teiid-client-8.7.1.6_2-redhat-3.jar:8.7.1.6_2-redhat-3]
at org.teiid.odbc.ODBCServerRemoteImpl$5.onCompletion(ODBCServerRemoteImpl.java:586) [teiid-runtime-8.7.1.6_2-redhat-3.jar:8.7.1.6_2-redhat-3]
at org.teiid.client.util.ResultsFuture.done(ResultsFuture.java:135) [teiid-client-8.7.1.6_2-redhat-3.jar:8.7.1.6_2-redhat-3]
at org.teiid.client.util.ResultsFuture.access$200(ResultsFuture.java:40) [teiid-client-8.7.1.6_2-redhat-3.jar:8.7.1.6_2-redhat-3]
at org.teiid.client.util.ResultsFuture$1.exceptionOccurred(ResultsFuture.java:68) [teiid-client-8.7.1.6_2-redhat-3.jar:8.7.1.6_2-redhat-3]
at org.teiid.jdbc.StatementImpl$2.onCompletion(StatementImpl.java:518) [teiid-client-8.7.1.6_2-redhat-3.jar:8.7.1.6_2-redhat-3]
at org.teiid.client.util.ResultsFuture.done(ResultsFuture.java:135) [teiid-client-8.7.1.6_2-redhat-3.jar:8.7.1.6_2-redhat-3]
at org.teiid.client.util.ResultsFuture.access$200(ResultsFuture.java:40) [teiid-client-8.7.1.6_2-redhat-3.jar:8.7.1.6_2-redhat-3]
at org.teiid.client.util.ResultsFuture$1.receiveResults(ResultsFuture.java:79) [teiid-client-8.7.1.6_2-redhat-3.jar:8.7.1.6_2-redhat-3]
at org.teiid.dqp.internal.process.RequestWorkItem.sendError(RequestWorkItem.java:1001) [teiid-engine-8.7.1.6_2-redhat-3.jar:8.7.1.6_2-redhat-3]
at org.teiid.dqp.internal.process.RequestWorkItem.close(RequestWorkItem.java:556) [teiid-engine-8.7.1.6_2-redhat-3.jar:8.7.1.6_2-redhat-3]
at org.teiid.dqp.internal.process.RequestWorkItem.process(RequestWorkItem.java:352) [teiid-engine-8.7.1.6_2-redhat-3.jar:8.7.1.6_2-redhat-3]
at org.teiid.dqp.internal.process.AbstractWorkItem.run(AbstractWorkItem.java:51) [teiid-engine-8.7.1.6_2-redhat-3.jar:8.7.1.6_2-redhat-3]
at org.teiid.dqp.internal.process.RequestWorkItem.run(RequestWorkItem.java:254) [teiid-engine-8.7.1.6_2-redhat-3.jar:8.7.1.6_2-redhat-3]
at org.teiid.dqp.internal.process.DQPWorkContext.runInContext(DQPWorkContext.java:274) [teiid-engine-8.7.1.6_2-redhat-3.jar:8.7.1.6_2-redhat-3]
at org.teiid.dqp.internal.process.ThreadReuseExecutor$RunnableWrapper.run(ThreadReuseExecutor.java:119) [teiid-engine-8.7.1.6_2-redhat-3.jar:8.7.1.6_2-redhat-3]
at org.teiid.dqp.internal.process.ThreadReuseExecutor$3.run(ThreadReuseExecutor.java:210) [teiid-engine-8.7.1.6_2-redhat-3.jar:8.7.1.6_2-redhat-3]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_75]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_75]
at java.lang.Thread.run(Thread.java:745) [rt.jar:1.7.0_75]
Caused by: org.teiid.jdbc.TeiidSQLException: TEIID30492 [EmployeeFixedData.EmployeeFixed.city] cannot be used outside of aggregate functions since they are not present in a GROUP BY clause.
at org.teiid.jdbc.TeiidSQLException.create(TeiidSQLException.java:135) [teiid-client-8.7.1.6_2-redhat-3.jar:8.7.1.6_2-redhat-3]
at org.teiid.jdbc.TeiidSQLException.create(TeiidSQLException.java:71) [teiid-client-8.7.1.6_2-redhat-3.jar:8.7.1.6_2-redhat-3]
at org.teiid.jdbc.StatementImpl.postReceiveResults(StatementImpl.java:667) [teiid-client-8.7.1.6_2-redhat-3.jar:8.7.1.6_2-redhat-3]
at org.teiid.jdbc.StatementImpl.access$100(StatementImpl.java:63) [teiid-client-8.7.1.6_2-redhat-3.jar:8.7.1.6_2-redhat-3]
at org.teiid.jdbc.StatementImpl$2.onCompletion(StatementImpl.java:515) [teiid-client-8.7.1.6_2-redhat-3.jar:8.7.1.6_2-redhat-3]
... 14 more
Caused by: org.teiid.api.exception.query.QueryValidatorException: TEIID30492 [EmployeeFixedData.EmployeeFixed.city] cannot be used outside of aggregate functions since they are not present in a GROUP BY clause.
at org.teiid.dqp.internal.process.Request.validateWithVisitor(Request.java:305) [teiid-engine-8.7.1.6_2-redhat-3.jar:8.7.1.6_2-redhat-3]
at org.teiid.dqp.internal.process.Request.validateQuery(Request.java:268) [teiid-engine-8.7.1.6_2-redhat-3.jar:8.7.1.6_2-redhat-3]
at org.teiid.dqp.internal.process.Request.generatePlan(Request.java:385) [teiid-engine-8.7.1.6_2-redhat-3.jar:8.7.1.6_2-redhat-3]
at org.teiid.dqp.internal.process.PreparedStatementRequest.generatePlan(PreparedStatementRequest.java:115) [teiid-engine-8.7.1.6_2-redhat-3.jar:8.7.1.6_2-redhat-3]
at org.teiid.dqp.internal.process.Request.processRequest(Request.java:435) [teiid-engine-8.7.1.6_2-redhat-3.jar:8.7.1.6_2-redhat-3]
at org.teiid.dqp.internal.process.PreparedStatementRequest.processRequest(PreparedStatementRequest.java:290) [teiid-engine-8.7.1.6_2-redhat-3.jar:8.7.1.6_2-redhat-3]
at org.teiid.dqp.internal.process.RequestWorkItem.processNew(RequestWorkItem.java:613) [teiid-engine-8.7.1.6_2-redhat-3.jar:8.7.1.6_2-redhat-3]
at org.teiid.dqp.internal.process.RequestWorkItem.process(RequestWorkItem.java:315) [teiid-engine-8.7.1.6_2-redhat-3.jar:8.7.1.6_2-redhat-3]
... 8 more
{code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
9 years, 6 months
[JBoss JIRA] (TEIID-3562) Teradata15 - teiid shifts date/time/timestamp values according to timezone.
by Juraj Duráni (JIRA)
[ https://issues.jboss.org/browse/TEIID-3562?page=com.atlassian.jira.plugin... ]
Juraj Duráni commented on TEIID-3562:
-------------------------------------
Verified.
> Teradata15 - teiid shifts date/time/timestamp values according to timezone.
> ---------------------------------------------------------------------------
>
> Key: TEIID-3562
> URL: https://issues.jboss.org/browse/TEIID-3562
> Project: Teiid
> Issue Type: Bug
> Affects Versions: 8.7.1.6_2
> Environment: teradata version - 15.00.01.01
> teradata driver version - 15.10.00.05
> Reporter: Juraj Duráni
> Assignee: Steven Hawkins
> Attachments: Main.java, out_GMT+0500, out_GMT_not_set
>
>
> Teiid shifts date/time/timestamp values returned from teradata according to user.timezone value [1], [2]. However, when I execute source-specific command, teradata returns correct values [3].
> [1]
> *Query:* SELECT * FROM smalla ORDER BY IntKey
> *-Duser.timezone:* GMT+5
> *Result:*
> || IntKey || DateValue || TimeValue || TimeStampValue ||
> |0 | 1999-12-31 | 19:00:00 | 1999-12-31 19:00:00.0|
> |1 | 2000-01-01 | 20:00:00 | 1999-12-31 19:00:01.0|
> |2 | 2000-01-02 | 21:00:00 | 1999-12-31 19:00:02.0|
> |3 | 2000-01-03 | 22:00:00 | 1999-12-31 19:00:03.0|
> |...|...|...|...|
> [2]
> *Query:* SELECT * FROM smalla ORDER BY IntKey
> *-Duser.timezone:* GMT+1
> *Result:*
> || IntKey || DateValue || TimeValue || TimeStampValue ||
> |0 | 1999-12-31 | 23:00:00 | 1999-12-31 23:00:00.0|
> |1 | 2000-01-01 | 00:00:00 | 1999-12-31 23:00:01.0|
> |2 | 2000-01-02 | 01:00:00 | 1999-12-31 23:00:02.0|
> |3 | 2000-01-03 | 02:00:00 | 1999-12-31 23:00:03.0|
> |...|...|...|...|
> [3]
> *Query:* SELECT g_0.IntKey AS c_0, g_0.DateValue AS c_1, g_0.TimeValue AS c_2, g_0.TimestampValue AS c_3 FROM smalla AS g_0 ORDER BY 1
> *local timezone:* GMT+1/GMT+5
> *Result:*
> || c_0 || c_1 || c_2 || c_3 ||
> |0 | 2000-01-01 | 00:00:00 | 2000-01-01 00:00:00.0|
> |1 | 2000-01-02 | 01:00:00 | 2000-01-01 00:00:01.0|
> |2 | 2000-01-03 | 02:00:00 | 2000-01-01 00:00:02.0|
> |3 | 2000-01-04 | 03:00:00 | 2000-01-01 00:00:03.0|
> |...|...|...|...|
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
9 years, 6 months
[JBoss JIRA] (TEIID-3573) Infinispan-dsl-cache translator: Operator <> incorrectly handles NULL values
by Van Halbert (JIRA)
[ https://issues.jboss.org/browse/TEIID-3573?page=com.atlassian.jira.plugin... ]
Van Halbert edited comment on TEIID-3573 at 7/15/15 9:15 AM:
-------------------------------------------------------------
This will problematic to implement, because its JDG that's doing the comparison. Teiid doesn't know that the column contains null values without some pre-reading.
Unless you're thinking of adding an additional filtering in the translator such that when a column that's used in the WHERE clause is returned that has a null value, and NULL or ISNULL checks are not used, then filter out the row?
was (Author: van.halbert):
This will problematic to implement, because its JDG that's doing the comparison. Teiid doesn't know that the column contains null values without some pre-reading.
> Infinispan-dsl-cache translator: Operator <> incorrectly handles NULL values
> ----------------------------------------------------------------------------
>
> Key: TEIID-3573
> URL: https://issues.jboss.org/browse/TEIID-3573
> Project: Teiid
> Issue Type: Bug
> Components: Misc. Connectors
> Affects Versions: 8.7.1
> Reporter: Filip Elias
> Assignee: Van Halbert
>
> Operator '<>' returns true for NULL <> 1
> Example:
> {code}
> select intKey,intNum from smallA where intNum<>1
> {code}
> It returns also rows which have NULL in column intNum
> I believe that NULL <> 1 is not true in SQL.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
9 years, 6 months
[JBoss JIRA] (TEIID-3573) Infinispan-dsl-cache translator: Operator <> incorrectly handles NULL values
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-3573?page=com.atlassian.jira.plugin... ]
Steven Hawkins commented on TEIID-3573:
---------------------------------------
null <> 1 would be unknown in sql. At a top level that is the same as false, but not(unknown) is also unknown. The engine will typically pushdown CNF so even if infinispan cannot support three valued logic, it should be ok. If they have a problem with null comparisons in general we can workaround that in master if needed.
> Infinispan-dsl-cache translator: Operator <> incorrectly handles NULL values
> ----------------------------------------------------------------------------
>
> Key: TEIID-3573
> URL: https://issues.jboss.org/browse/TEIID-3573
> Project: Teiid
> Issue Type: Bug
> Components: Misc. Connectors
> Affects Versions: 8.7.1
> Reporter: Filip Elias
> Assignee: Van Halbert
>
> Operator '<>' returns true for NULL <> 1
> Example:
> {code}
> select intKey,intNum from smallA where intNum<>1
> {code}
> It returns also rows which have NULL in column intNum
> I believe that NULL <> 1 is not true in SQL.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
9 years, 6 months
[JBoss JIRA] (TEIID-3562) Teradata15 - teiid shifts date/time/timestamp values according to timezone.
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-3562?page=com.atlassian.jira.plugin... ]
Steven Hawkins commented on TEIID-3562:
---------------------------------------
If you can verify that, I'll add a doc note.
> Teradata15 - teiid shifts date/time/timestamp values according to timezone.
> ---------------------------------------------------------------------------
>
> Key: TEIID-3562
> URL: https://issues.jboss.org/browse/TEIID-3562
> Project: Teiid
> Issue Type: Bug
> Affects Versions: 8.7.1.6_2
> Environment: teradata version - 15.00.01.01
> teradata driver version - 15.10.00.05
> Reporter: Juraj Duráni
> Assignee: Steven Hawkins
> Attachments: Main.java, out_GMT+0500, out_GMT_not_set
>
>
> Teiid shifts date/time/timestamp values returned from teradata according to user.timezone value [1], [2]. However, when I execute source-specific command, teradata returns correct values [3].
> [1]
> *Query:* SELECT * FROM smalla ORDER BY IntKey
> *-Duser.timezone:* GMT+5
> *Result:*
> || IntKey || DateValue || TimeValue || TimeStampValue ||
> |0 | 1999-12-31 | 19:00:00 | 1999-12-31 19:00:00.0|
> |1 | 2000-01-01 | 20:00:00 | 1999-12-31 19:00:01.0|
> |2 | 2000-01-02 | 21:00:00 | 1999-12-31 19:00:02.0|
> |3 | 2000-01-03 | 22:00:00 | 1999-12-31 19:00:03.0|
> |...|...|...|...|
> [2]
> *Query:* SELECT * FROM smalla ORDER BY IntKey
> *-Duser.timezone:* GMT+1
> *Result:*
> || IntKey || DateValue || TimeValue || TimeStampValue ||
> |0 | 1999-12-31 | 23:00:00 | 1999-12-31 23:00:00.0|
> |1 | 2000-01-01 | 00:00:00 | 1999-12-31 23:00:01.0|
> |2 | 2000-01-02 | 01:00:00 | 1999-12-31 23:00:02.0|
> |3 | 2000-01-03 | 02:00:00 | 1999-12-31 23:00:03.0|
> |...|...|...|...|
> [3]
> *Query:* SELECT g_0.IntKey AS c_0, g_0.DateValue AS c_1, g_0.TimeValue AS c_2, g_0.TimestampValue AS c_3 FROM smalla AS g_0 ORDER BY 1
> *local timezone:* GMT+1/GMT+5
> *Result:*
> || c_0 || c_1 || c_2 || c_3 ||
> |0 | 2000-01-01 | 00:00:00 | 2000-01-01 00:00:00.0|
> |1 | 2000-01-02 | 01:00:00 | 2000-01-01 00:00:01.0|
> |2 | 2000-01-03 | 02:00:00 | 2000-01-01 00:00:02.0|
> |3 | 2000-01-04 | 03:00:00 | 2000-01-01 00:00:03.0|
> |...|...|...|...|
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
9 years, 6 months
[JBoss JIRA] (TEIID-3296) Some criteria are missing when indexes are used on the source tables
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/TEIID-3296?page=com.atlassian.jira.plugin... ]
RH Bugzilla Integration commented on TEIID-3296:
------------------------------------------------
Jan Stastny <jstastny(a)redhat.com> changed the Status of [bug 1207222|https://bugzilla.redhat.com/show_bug.cgi?id=1207222] from ON_QA to VERIFIED
> Some criteria are missing when indexes are used on the source tables
> --------------------------------------------------------------------
>
> Key: TEIID-3296
> URL: https://issues.jboss.org/browse/TEIID-3296
> Project: Teiid
> Issue Type: Bug
> Components: Query Engine
> Affects Versions: 8.2
> Reporter: Salvatore R
> Assignee: Steven Hawkins
> Priority: Blocker
> Fix For: 8.10, 8.7.2, 8.7.1.6_2
>
>
> The following two tables are defined in two different datasources (PostgreSQL and MySQL):
> {code:sql}
> CREATE TABLE "pg"."tx1"
> (
> a varchar(2147483647),
> b varchar(2147483647),
> c integer,
> d integer,
> e integer
> );
> CREATE INDEX tx1_b ON "pg"."tx1"(b);
> CREATE INDEX tx1_a ON "pg"."tx1"(a);
> CREATE INDEX tx1_e ON "pg"."tx1"(e);
> CREATE INDEX tx1_d ON "pg"."tx1"(d);
> CREATE INDEX tx1_c ON "pg"."tx1"(c);
>
> CREATE TABLE "my"."tx2"
> (
> a integer,
> b integer,
> c integer,
> d integer,
> e integer
> );
> insert into tx1 VALUES(1,1,1,1,1) ;
> insert into tx1 VALUES(1,2,2,2,2) ;
> insert into tx1 VALUES(1,2,3,3,3) ;
> insert into tx1 VALUES(1,2,3,4,4) ;
> insert into tx1 VALUES(1,2,3,4,5) ;
> insert into tx2 VALUES(1,2,3,4,5) ;
> {code}
> Running the following query:
> {code:sql}
> select tx1.* from pg.tx1 as tx1 join my.tx2 as tx2 on tx1.a=tx2.a and tx1.b=tx2.b and tx1.c=tx2.c and tx1.d=tx2.d and tx1.e!=tx2.e;
> {code}
> a wrong result is returned:
> ||a||b||c||d||e||
> |1|2|2|2|2|
> |1|2|3|3|3|
> |1|2|3|4|4|
> If indexes are removed from the source table, the expected result is correctly returned:
> ||a||b||c||d||e||
> |1|2|3|4|4|
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
9 years, 6 months