[JBoss JIRA] (TEIID-4875) Planning issue with multiple aggregate decompositions through a join tree
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-4875?page=com.atlassian.jira.plugin... ]
Steven Hawkins resolved TEIID-4875.
-----------------------------------
Resolution: Done
Changed the logic to recollect the aggregates when a modification is introduced that may affect other staged aggregates.
> Planning issue with multiple aggregate decompositions through a join tree
> -------------------------------------------------------------------------
>
> Key: TEIID-4875
> URL: https://issues.jboss.org/browse/TEIID-4875
> Project: Teiid
> Issue Type: Bug
> Components: Query Engine
> Reporter: Steven Hawkins
> Assignee: Steven Hawkins
> Fix For: 9.3, 9.2.3
>
>
> The logic for determining other symbols from aggregates will not work correctly when a staged grouping is initially pushed and another staged grouping is then pushed above a join that is above that location (typically due to join predicates that pull in other groups).
> A query such as:
> SELECT max(t3.e4), max(t2.e4) as s FROM pm1.g1 as t1, pm1.g2 as t2, pm1.g3 as t3, pm1.g4 as t4, pm2.g1 as t5 WHERE t1.e1 = t2.e1 and (t2.e2 = t3.e2 and t1.e3 || t2.e3 = t3.e3) and t3.e3 = t4.e3 and t4.e4 = t5.e4
> With capabilities that disable join pushdown will fail with an assertionerror that a staged grouping symbol cannot be found during the initialization of the parent join node.
> java.lang.AssertionError: ASSERTION FAILED: expected reference to be not null
> at org.teiid.core.util.Assertion.failed(Assertion.java:73)
> at org.teiid.core.util.Assertion.isNotNull(Assertion.java:100)
> at org.teiid.core.util.Assertion.isNotNull(Assertion.java:92)
> at org.teiid.query.processor.relational.RelationalNode.getProjectionIndexes(RelationalNode.java:367)
> at org.teiid.query.processor.relational.JoinNode.initialize(JoinNode.java:133)
> at org.teiid.query.processor.relational.RelationalPlan.connectExternal(RelationalPlan.java:96)
> at org.teiid.query.processor.relational.RelationalPlan.connectExternal(RelationalPlan.java:102)
> at org.teiid.query.processor.relational.RelationalPlan.connectExternal(RelationalPlan.java:102)
> at org.teiid.query.processor.relational.RelationalPlan.initialize(RelationalPlan.java:91)
> at org.teiid.query.processor.QueryProcessor.init(QueryProcessor.java:226)
> at org.teiid.query.processor.QueryProcessor.nextBatchDirect(QueryProcessor.java:138)
> at org.teiid.query.processor.QueryProcessor.nextBatch(QueryProcessor.java:114)
> at org.teiid.query.processor.BatchCollector.collectTuples(BatchCollector.java:164)
> at org.teiid.query.processor.BatchCollector.collectTuples(BatchCollector.java:146)
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 8 months
[JBoss JIRA] (TEIID-4824) Add unique id as a configuration property in the Google Resource adapter
by Van Halbert (JIRA)
[ https://issues.jboss.org/browse/TEIID-4824?page=com.atlassian.jira.plugin... ]
Van Halbert updated TEIID-4824:
-------------------------------
Fix Version/s: 8.12.x-6.4
> Add unique id as a configuration property in the Google Resource adapter
> ------------------------------------------------------------------------
>
> Key: TEIID-4824
> URL: https://issues.jboss.org/browse/TEIID-4824
> Project: Teiid
> Issue Type: Enhancement
> Components: Misc. Connectors
> Affects Versions: 8.12.8.6_3
> Reporter: Debbie Steigner
> Assignee: Steven Hawkins
> Fix For: 9.3, 8.12.x-6.4
>
>
> Currently, only the google spreadsheet name can be used in the Google Resource adapter instead of the unique id of the document. If there is more than one document with same name in multiple folders the wrong file may be picked up by the resource adapter. Is it possible to use unique document ID instead of spreadsheet name for google data source
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 8 months
[JBoss JIRA] (TEIID-4858) hive translator is extremely slow
by Michael Echevarria (JIRA)
[ https://issues.jboss.org/browse/TEIID-4858?page=com.atlassian.jira.plugin... ]
Michael Echevarria updated TEIID-4858:
--------------------------------------
Workaround Description: Use simple-jdbc or override the orderBy option in the hive translator (was: Do not use the hive translator and only use jdbc)
> hive translator is extremely slow
> ---------------------------------
>
> Key: TEIID-4858
> URL: https://issues.jboss.org/browse/TEIID-4858
> Project: Teiid
> Issue Type: Bug
> Components: JDBC Connector
> Affects Versions: 8.12.9.6_3
> Environment: Tested against JDV 6.3.4 and the Cloudera quickstart 5.8 VM with the Cloudera sample data loaded into hive
> Reporter: Michael Echevarria
> Assignee: Steven Hawkins
> Attachments: fast.log, override1.png, override2.png, slow.log
>
>
> When querying a table through the hive translator the results take close to 30 seconds to return.
> When querying a table through jdbc default results take under 1 second to return.
> Both use the same underlying jboss server datasource.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 8 months
[JBoss JIRA] (TEIID-4858) hive translator is extremely slow
by Michael Echevarria (JIRA)
[ https://issues.jboss.org/browse/TEIID-4858?page=com.atlassian.jira.plugin... ]
Michael Echevarria commented on TEIID-4858:
-------------------------------------------
Yep, the override worked perfectly. I attached a couple screenshots so that others could see where to make the changes in the designer if they chose to do so.
> hive translator is extremely slow
> ---------------------------------
>
> Key: TEIID-4858
> URL: https://issues.jboss.org/browse/TEIID-4858
> Project: Teiid
> Issue Type: Bug
> Components: JDBC Connector
> Affects Versions: 8.12.9.6_3
> Environment: Tested against JDV 6.3.4 and the Cloudera quickstart 5.8 VM with the Cloudera sample data loaded into hive
> Reporter: Michael Echevarria
> Assignee: Steven Hawkins
> Attachments: fast.log, override1.png, override2.png, slow.log
>
>
> When querying a table through the hive translator the results take close to 30 seconds to return.
> When querying a table through jdbc default results take under 1 second to return.
> Both use the same underlying jboss server datasource.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 8 months
[JBoss JIRA] (TEIID-4858) hive translator is extremely slow
by Michael Echevarria (JIRA)
[ https://issues.jboss.org/browse/TEIID-4858?page=com.atlassian.jira.plugin... ]
Michael Echevarria updated TEIID-4858:
--------------------------------------
Attachment: override1.png
> hive translator is extremely slow
> ---------------------------------
>
> Key: TEIID-4858
> URL: https://issues.jboss.org/browse/TEIID-4858
> Project: Teiid
> Issue Type: Bug
> Components: JDBC Connector
> Affects Versions: 8.12.9.6_3
> Environment: Tested against JDV 6.3.4 and the Cloudera quickstart 5.8 VM with the Cloudera sample data loaded into hive
> Reporter: Michael Echevarria
> Assignee: Steven Hawkins
> Attachments: fast.log, override1.png, override2.png, slow.log
>
>
> When querying a table through the hive translator the results take close to 30 seconds to return.
> When querying a table through jdbc default results take under 1 second to return.
> Both use the same underlying jboss server datasource.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 8 months
[JBoss JIRA] (TEIID-4858) hive translator is extremely slow
by Michael Echevarria (JIRA)
[ https://issues.jboss.org/browse/TEIID-4858?page=com.atlassian.jira.plugin... ]
Michael Echevarria updated TEIID-4858:
--------------------------------------
Attachment: override2.png
> hive translator is extremely slow
> ---------------------------------
>
> Key: TEIID-4858
> URL: https://issues.jboss.org/browse/TEIID-4858
> Project: Teiid
> Issue Type: Bug
> Components: JDBC Connector
> Affects Versions: 8.12.9.6_3
> Environment: Tested against JDV 6.3.4 and the Cloudera quickstart 5.8 VM with the Cloudera sample data loaded into hive
> Reporter: Michael Echevarria
> Assignee: Steven Hawkins
> Attachments: fast.log, override1.png, override2.png, slow.log
>
>
> When querying a table through the hive translator the results take close to 30 seconds to return.
> When querying a table through jdbc default results take under 1 second to return.
> Both use the same underlying jboss server datasource.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 8 months
[JBoss JIRA] (TEIID-4875) Planning issue with multiple aggregate decompositions through a join tree
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-4875?page=com.atlassian.jira.plugin... ]
Steven Hawkins updated TEIID-4875:
----------------------------------
Description:
The logic for determining other symbols from aggregates will not work correctly when a staged grouping is initially pushed and another staged grouping is then pushed above a join that is above that location (typically due to join predicates that pull in other groups).
A query such as:
SELECT max(t3.e4), max(t2.e4) as s FROM pm1.g1 as t1, pm1.g2 as t2, pm1.g3 as t3, pm1.g4 as t4, pm2.g1 as t5 WHERE t1.e1 = t2.e1 and (t2.e2 = t3.e2 and t1.e3 || t2.e3 = t3.e3) and t3.e3 = t4.e3 and t4.e4 = t5.e4
With capabilities that disable join pushdown will fail with an assertionerror that a staged grouping symbol cannot be found during the initialization of the parent join node.
java.lang.AssertionError: ASSERTION FAILED: expected reference to be not null
at org.teiid.core.util.Assertion.failed(Assertion.java:73)
at org.teiid.core.util.Assertion.isNotNull(Assertion.java:100)
at org.teiid.core.util.Assertion.isNotNull(Assertion.java:92)
at org.teiid.query.processor.relational.RelationalNode.getProjectionIndexes(RelationalNode.java:367)
at org.teiid.query.processor.relational.JoinNode.initialize(JoinNode.java:133)
at org.teiid.query.processor.relational.RelationalPlan.connectExternal(RelationalPlan.java:96)
at org.teiid.query.processor.relational.RelationalPlan.connectExternal(RelationalPlan.java:102)
at org.teiid.query.processor.relational.RelationalPlan.connectExternal(RelationalPlan.java:102)
at org.teiid.query.processor.relational.RelationalPlan.initialize(RelationalPlan.java:91)
at org.teiid.query.processor.QueryProcessor.init(QueryProcessor.java:226)
at org.teiid.query.processor.QueryProcessor.nextBatchDirect(QueryProcessor.java:138)
at org.teiid.query.processor.QueryProcessor.nextBatch(QueryProcessor.java:114)
at org.teiid.query.processor.BatchCollector.collectTuples(BatchCollector.java:164)
at org.teiid.query.processor.BatchCollector.collectTuples(BatchCollector.java:146)
was:
The logic for determining other symbols from aggregates will not work correctly when a staged grouping is initially pushed and another staged grouping is then pushed above a join that is above that location (typically due to join predicates that pull in other groups).
A query such as:
SELECT max(t3.e4), max(t2.e4) as s FROM pm1.g1 as t1, pm1.g2 as t2, pm1.g3 as t3, pm1.g4 as t4, pm2.g1 as t5 WHERE t1.e1 = t2.e1 and (t2.e2 = t3.e2 and t1.e3 || t2.e3 = t3.e3) and t3.e3 = t4.e3 and t4.e4 = t5.e4
Will fail with an assertionerror that a staged grouping symbol cannot be found during the initialization of the parent join node.
> Planning issue with multiple aggregate decompositions through a join tree
> -------------------------------------------------------------------------
>
> Key: TEIID-4875
> URL: https://issues.jboss.org/browse/TEIID-4875
> Project: Teiid
> Issue Type: Bug
> Components: Query Engine
> Reporter: Steven Hawkins
> Assignee: Steven Hawkins
> Fix For: 9.3, 9.2.3
>
>
> The logic for determining other symbols from aggregates will not work correctly when a staged grouping is initially pushed and another staged grouping is then pushed above a join that is above that location (typically due to join predicates that pull in other groups).
> A query such as:
> SELECT max(t3.e4), max(t2.e4) as s FROM pm1.g1 as t1, pm1.g2 as t2, pm1.g3 as t3, pm1.g4 as t4, pm2.g1 as t5 WHERE t1.e1 = t2.e1 and (t2.e2 = t3.e2 and t1.e3 || t2.e3 = t3.e3) and t3.e3 = t4.e3 and t4.e4 = t5.e4
> With capabilities that disable join pushdown will fail with an assertionerror that a staged grouping symbol cannot be found during the initialization of the parent join node.
> java.lang.AssertionError: ASSERTION FAILED: expected reference to be not null
> at org.teiid.core.util.Assertion.failed(Assertion.java:73)
> at org.teiid.core.util.Assertion.isNotNull(Assertion.java:100)
> at org.teiid.core.util.Assertion.isNotNull(Assertion.java:92)
> at org.teiid.query.processor.relational.RelationalNode.getProjectionIndexes(RelationalNode.java:367)
> at org.teiid.query.processor.relational.JoinNode.initialize(JoinNode.java:133)
> at org.teiid.query.processor.relational.RelationalPlan.connectExternal(RelationalPlan.java:96)
> at org.teiid.query.processor.relational.RelationalPlan.connectExternal(RelationalPlan.java:102)
> at org.teiid.query.processor.relational.RelationalPlan.connectExternal(RelationalPlan.java:102)
> at org.teiid.query.processor.relational.RelationalPlan.initialize(RelationalPlan.java:91)
> at org.teiid.query.processor.QueryProcessor.init(QueryProcessor.java:226)
> at org.teiid.query.processor.QueryProcessor.nextBatchDirect(QueryProcessor.java:138)
> at org.teiid.query.processor.QueryProcessor.nextBatch(QueryProcessor.java:114)
> at org.teiid.query.processor.BatchCollector.collectTuples(BatchCollector.java:164)
> at org.teiid.query.processor.BatchCollector.collectTuples(BatchCollector.java:146)
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 8 months
[JBoss JIRA] (TEIID-4875) Planning issue with multiple aggregate decompositions through a join tree
by Steven Hawkins (JIRA)
Steven Hawkins created TEIID-4875:
-------------------------------------
Summary: Planning issue with multiple aggregate decompositions through a join tree
Key: TEIID-4875
URL: https://issues.jboss.org/browse/TEIID-4875
Project: Teiid
Issue Type: Bug
Components: Query Engine
Reporter: Steven Hawkins
Assignee: Steven Hawkins
Fix For: 9.3, 9.2.3
The logic for determining other symbols from aggregates will not work correctly when a staged grouping is initially pushed and another staged grouping is then pushed above a join that is above that location (typically due to join predicates that pull in other groups).
A query such as:
SELECT max(t3.e4), max(t2.e4) as s FROM pm1.g1 as t1, pm1.g2 as t2, pm1.g3 as t3, pm1.g4 as t4, pm2.g1 as t5 WHERE t1.e1 = t2.e1 and (t2.e2 = t3.e2 and t1.e3 || t2.e3 = t3.e3) and t3.e3 = t4.e3 and t4.e4 = t5.e4
Will fail with an assertionerror that a staged grouping symbol cannot be found during the initialization of the parent join node.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 8 months
[JBoss JIRA] (TEIID-4874) SQL Server translator should support full outer join by default
by Steven Hawkins (JIRA)
Steven Hawkins created TEIID-4874:
-------------------------------------
Summary: SQL Server translator should support full outer join by default
Key: TEIID-4874
URL: https://issues.jboss.org/browse/TEIID-4874
Project: Teiid
Issue Type: Bug
Components: JDBC Connector
Reporter: Steven Hawkins
Assignee: Steven Hawkins
Fix For: 9.3, 9.2.3
Due to inheriting from the sybase translator, the sqlserver translator by default does not support full outer join. This should changed to true.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 8 months
[JBoss JIRA] (TEIID-4854) Google translator fails to update timestamp value reformatted after update
by Lucie Fabrikova (JIRA)
[ https://issues.jboss.org/browse/TEIID-4854?page=com.atlassian.jira.plugin... ]
Lucie Fabrikova edited comment on TEIID-4854 at 4/23/17 1:06 AM:
-----------------------------------------------------------------
If timestamp value is reformatted, query 'SELECT TimestampValue from SmallA' produces two different results depending on sheet content:
1. If there is no other row (only header row), exception is thrown 'Could not convert source column Source.smalla.timestampvalue to the expected runtime type timestamp'
2. if there is present some other row with correctly formatted timestamp value, null is return for reformatted TimeStampValue
was (Author: lfabriko):
If timestamp value is reformatted, query 'SELECT TimestampValue from SmallA' produces two different results depending on sheet content:
1. If there is no other row (only header and this one), exception is thrown 'Could not convert source column Source.smalla.timestampvalue to the expected runtime type timestamp'
2. if there is present some other row with correctly formatted timestamp value, null is return for reformatted TimeStampValue
> Google translator fails to update timestamp value reformatted after update
> --------------------------------------------------------------------------
>
> Key: TEIID-4854
> URL: https://issues.jboss.org/browse/TEIID-4854
> Project: Teiid
> Issue Type: Bug
> Affects Versions: 9.3, 8.12.10.6_3
> Reporter: Lucie Fabrikova
> Assignee: Steven Hawkins
> Fix For: 9.3
>
> Attachments: gs-reformatted-timestamp.log
>
>
> Cell of type timestamp is reformatted after an update. Data inserted from teiid are in format "yyyy-mm-dd hh:mm:ss[.fffffffff]", which is reformatted to "dd/mm/yyyy hh:mm:ss[.fffffffff]". Subsequent update of such row throws exception "Could not convert source column Source.smalla.timestampvalue to the expected runtime type timestamp".
> Google spreadsheet locale was UK, timezone was set to Berlin.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 8 months