[JBoss JIRA] Created: (TEIID-1503) Exception during Optimization
by Ramesh Reddy (JIRA)
Exception during Optimization
------------------------------
Key: TEIID-1503
URL: https://issues.jboss.org/browse/TEIID-1503
Project: Teiid
Issue Type: Bug
Components: Query Engine
Affects Versions: 7.4
Reporter: Ramesh Reddy
Assignee: Steven Hawkins
Fix For: 7.4
while running the BQT Query
SELECT intkey FROM BQT1.SmallA AS A WHERE convert(shortvalue, integer) = (SELECT MAX(convert(shortvalue, integer)) FROM BQT1.SmallA AS B WHERE b.intnum = a.intnum) ORDER BY intkey
I encountered
java.lang.ArrayIndexOutOfBoundsException: -1
at java.util.ArrayList.get(ArrayList.java:324)
at org.teiid.query.optimizer.relational.rules.RuleAssignOutputElements.filterVirtualElements(RuleAssignOutputElements.java:358)
at org.teiid.query.optimizer.relational.rules.RuleAssignOutputElements.assignOutputElements(RuleAssignOutputElements.java:168)
at org.teiid.query.optimizer.relational.rules.RuleAssignOutputElements.assignOutputElements(RuleAssignOutputElements.java:217)
at org.teiid.query.optimizer.relational.rules.RuleAssignOutputElements.assignOutputElements(RuleAssignOutputElements.java:217)
at org.teiid.query.optimizer.relational.rules.RuleAssignOutputElements.assignOutputElements(RuleAssignOutputElements.java:163)
at org.teiid.query.optimizer.relational.rules.RuleAssignOutputElements.execute(RuleAssignOutputElements.java:96)
at org.teiid.query.optimizer.relational.RelationalPlanner.executeRules(RelationalPlanner.java:462)
at org.teiid.query.optimizer.relational.RelationalPlanner.optimize(RelationalPlanner.java:227)
at org.teiid.query.optimizer.QueryOptimizer.optimizePlan(QueryOptimizer.java:169)
at org.teiid.query.optimizer.relational.rules.RuleMergeCriteria.planSemiJoin(RuleMergeCriteria.java:283)
at org.teiid.query.optimizer.relational.rules.RuleMergeCriteria.findCriteriaChains(RuleMergeCriteria.java:170)
at org.teiid.query.optimizer.relational.rules.RuleMergeCriteria.findCriteriaChains(RuleMergeCriteria.java:189)
at org.teiid.query.optimizer.relational.rules.RuleMergeCriteria.findCriteriaChains(RuleMergeCriteria.java:189)
at org.teiid.query.optimizer.relational.rules.RuleMergeCriteria.findCriteriaChains(RuleMergeCriteria.java:189)
at org.teiid.query.optimizer.relational.rules.RuleMergeCriteria.execute(RuleMergeCriteria.java:146)
at org.teiid.query.optimizer.relational.RelationalPlanner.executeRules(RelationalPlanner.java:462)
at org.teiid.query.optimizer.relational.RelationalPlanner.optimize(RelationalPlanner.java:227)
at org.teiid.query.optimizer.QueryOptimizer.optimizePlan(QueryOptimizer.java:169)
at org.teiid.dqp.internal.process.Request.generatePlan(Request.java:429)
at org.teiid.dqp.internal.process.Request.processRequest(Request.java:452)
at org.teiid.dqp.internal.process.RequestWorkItem.processNew(RequestWorkItem.java:376)
at org.teiid.dqp.internal.process.RequestWorkItem.process(RequestWorkItem.java:175)
at org.teiid.dqp.internal.process.AbstractWorkItem.run(AbstractWorkItem.java:49)
at org.teiid.dqp.internal.process.DQPWorkContext.runInContext(DQPWorkContext.java:188)
at org.teiid.dqp.internal.process.ThreadReuseExecutor$RunnableWrapper.run(ThreadReuseExecutor.java:116)
at org.teiid.dqp.internal.process.ThreadReuseExecutor$3.run(ThreadReuseExecutor.java:290)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:619)
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 10 months
[JBoss JIRA] Created: (TEIID-1509) Change the default for value caching
by Steven Hawkins (JIRA)
Change the default for value caching
------------------------------------
Key: TEIID-1509
URL: https://issues.jboss.org/browse/TEIID-1509
Project: Teiid
Issue Type: Quality Risk
Components: Query Engine
Affects Versions: 7.4
Reporter: Steven Hawkins
Assignee: Steven Hawkins
Fix For: 7.4
There is a larger performance impact from having value caching enabled with large data sets (which is the more typical deployment scenario) than having value caching disabled and a larger memory footprint.
So the value caching default should change to false.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 10 months
[JBoss JIRA] Created: (TEIID-1481) client url cleanups
by Steven Hawkins (JIRA)
client url cleanups
-------------------
Key: TEIID-1481
URL: https://issues.jboss.org/browse/TEIID-1481
Project: Teiid
Issue Type: Task
Components: JDBC Driver
Affects Versions: 7.4
Reporter: Steven Hawkins
Assignee: Steven Hawkins
Fix For: 7.4
Designer is now leveraging the TeiidURL class for validation of server urls. The messages need internationalized and it would be better to through a checked exception (such as MalformedUrlException) rather than IllegalArgumentException.
In addition there is a lot of redundancy with url handling in the Socket/EmbeddedProfile, JDBCURL, and TeiidDataSource. This should be consolidated as much as possible.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 10 months
[JBoss JIRA] Created: (TEIID-1508) Dependent join planning problem
by Steven Hawkins (JIRA)
Dependent join planning problem
-------------------------------
Key: TEIID-1508
URL: https://issues.jboss.org/browse/TEIID-1508
Project: Teiid
Issue Type: Quality Risk
Components: Query Engine
Affects Versions: 7.4
Reporter: Steven Hawkins
Assignee: Steven Hawkins
Fix For: 7.4
Without a dependent join hint a composite cross source dependent join will not plan correctly unless the independent side can be pushed as a single query. The root of the issue is that join planning involving more than 1 independent table does not consider the effect of potential dependent joins early enough.
The workaround is to use a dependent join hint or set the cardinality of the independent tables small enough to trigger the proper dependent join.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 10 months
[JBoss JIRA] Created: (TEIID-1458) Wrong count(*) result when joining data from two models
by Claudio Venturini (JIRA)
Wrong count(*) result when joining data from two models
-------------------------------------------------------
Key: TEIID-1458
URL: https://issues.jboss.org/browse/TEIID-1458
Project: Teiid
Issue Type: Bug
Components: Query Engine
Affects Versions: 7.3, 7.2
Environment: Teiid 7.3 deployed on Jboss AS 5.1.0 GA running on Ubuntu Server 10.04 LTS, MySQL 5.1.51 running on the same maching as JBoss, SQL Server 2000 Standard SP4 running on Windows Server 2003
Reporter: Claudio Venturini
Assignee: Steven Hawkins
count(\*) gets a wrong result when is performed in a query which joins two tables coming from two different models.
The first (named "sqlsrv") is a source model for a table stored in SQL Server 2000. The second (named "mysql") is a source model for a table stored in MySQl 5.1.
The query performs an inner join on the column "product_id", which is shared by the two tables. All records match correctly, so there should be no difference in using an inner join instead of other join types.
The query is the following:
{noformat}
SELECT
invoice,
invoice_date,
code,
sum(quantity) AS s,
avg(price) AS av,
count(*) AS dim
FROM
sqlsrv.test2.dbo.sales SL
INNER JOIN mysql.test.product_code PC ON SL.product_id = PC.product_id
GROUP BY invoice_date, invoice, code
ORDER BY invoice_date ASC, invoice ASC, code ASC
{noformat}
The result of count(\*) is 1 for all records, while for some of them it should be 2, as there are duplicate records in the sales table, which are grouped by the GROUP BY clause.
Note that the problem exists only with the inner join. Left, right and outer joins work well, even if the set of records that they produce is the same as that produced by the inner join.
I noticed the problem in Teiid 7.2. Tonight I upgraded to 7.3, but the problem is still there.
If the data are all in the same DB, the query works as expected. It is not significant in which of the two DB each table resides. I think it is neither a problem of the SQL Server connector, nor of the MySQL connector.
The data are the following:
*product_code*:
||code||category||product_id||
|1|1|125|
|2|1|127|
|3|1|123|
|4|1|121|
|5|1|126|
|6|1|124|
|7|1|122|
*sales*:
||invoice||invoice_date||product_id||quantity||price||
|009831|2009-08-15 00:00:00|125|350|1.070261|
|009831|2009-08-15 00:00:00|124|960|1.070261|
|009843|2009-08-15 00:00:00|121|648|1.515264|
|009843|2009-08-15 00:00:00|126|145|2.763902|
|009843|2009-08-15 00:00:00|126|25|2.407148|
|009855|2009-08-15 00:00:00|122|768|1.122835|
|009855|2009-08-15 00:00:00|123|540|1.158511|
|009855|2009-08-15 00:00:00|125|480|1.070261|
|009857|2009-08-15 00:00:00|122|440|1.498365|
|009857|2009-08-15 00:00:00|126|115|2.585525|
|009866|2009-08-15 00:00:00|122|736|1.498365|
|009866|2009-08-15 00:00:00|123|558|1.391339|
|009866|2009-08-15 00:00:00|125|378|1.336887|
|009866|2009-08-15 00:00:00|127|510|1.605391|
|009866|2009-08-15 00:00:00|126|435|2.585525|
|009847|2009-08-15 00:00:00|126|55|2.763902|
|009847|2009-08-15 00:00:00|126|5|2.407148|
|009847|2009-08-15 00:00:00|121|240|1.872018|
The result of the above query is:
||invoice||invoice_date||code||s||av||dim||
|009831|2009-08-15 00:00:00|1|350.0|1.070261|1|
|009831|2009-08-15 00:00:00|6|960.0|1.070261|1|
|009843|2009-08-15 00:00:00|4|648.0|1.515264|1|
|009843|2009-08-15 00:00:00|5|170.0|2.585525|1|
|009847|2009-08-15 00:00:00|4|240.0|1.872018|1|
|009847|2009-08-15 00:00:00|5|60.0|2.585525|1|
|009855|2009-08-15 00:00:00|1|480.0|1.070261|1|
|009855|2009-08-15 00:00:00|3|540.0|1.158511|1|
|009855|2009-08-15 00:00:00|7|768.0|1.122835|1|
|009857|2009-08-15 00:00:00|5|115.0|2.585525|1|
|009857|2009-08-15 00:00:00|7|440.0|1.498365|1|
|009866|2009-08-15 00:00:00|1|378.0|1.336887|1|
|009866|2009-08-15 00:00:00|2|510.0|1.605391|1|
|009866|2009-08-15 00:00:00|3|558.0|1.391339|1|
|009866|2009-08-15 00:00:00|5|435.0|2.585525|1|
|009866|2009-08-15 00:00:00|7|736.0|1.498365|1|
As you can see, count(\*) (the "dim" column) always returns 1, even if it should return 2 for the product with id 126 in invoices 009843 and 009847.
If needed, I can provide you the two source models, and a dump of the two DBs.
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 10 months