November 2011 - teiid-issues - Jboss List Archives

[JBoss JIRA] (TEIID-1792) Inefficient plan using cartesian join

by Steven Hawkins (Closed) (JIRA)

[ https://issues.jboss.org/browse/TEIID-1792?page=com.atlassian.jira.plugin... ] Steven Hawkins closed TEIID-1792. --------------------------------- > Inefficient plan using cartesian join > ------------------------------------- > > Key: TEIID-1792 > URL: https://issues.jboss.org/browse/TEIID-1792 > Project: Teiid > Issue Type: Bug > Components: Query Engine > Affects Versions: 7.4.1 > Reporter: Debbie Steigner > Assignee: Steven Hawkins > Priority: Critical > Fix For: 7.4, 7.6 > > > We're trying to write a federated query, and we can't get Teiid to create an optimal plan. It is using a cartesian join, which causes Teiid to take a few hours and run out of memory, when we should be fetching a relatively small number of rows. We have tried using the new MAKEIND hint in 5.2, but Teiid seems to ignore it in this case. > See the SOA jura for more information. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 4 months

1
0
0 / 0

[JBoss JIRA] Created: (TEIID-1738) Temp table permissions can be confusing

by Steven Hawkins (JIRA)

Temp table permissions can be confusing --------------------------------------- Key: TEIID-1738 URL: https://issues.jboss.org/browse/TEIID-1738 Project: Teiid Issue Type: Quality Risk Components: Query Engine Affects Versions: 7.4 Reporter: Steven Hawkins Assignee: Steven Hawkins Fix For: 7.4.1, 7.6 The checking of temptable permissions currently returns the first non-null permission from the role set. This is different than the additive behavior of all other permissions. It means that setting a role to explicitly not be able to create temp tables may inappropriately deny a user from creating temp tables if a later role explicitly grants the permission. The permission determination logic should be: if any role allows return allow if any role doesn't allow return not allowed return the allowCreateTempTablesByDefault setting -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 4 months

2
2
0 / 0

[JBoss JIRA] Created: (TEIID-1686) Assertion failure when using a plan result buffer

by Steven Hawkins (JIRA)

Assertion failure when using a plan result buffer ------------------------------------------------- Key: TEIID-1686 URL: https://issues.jboss.org/browse/TEIID-1686 Project: Teiid Issue Type: Bug Components: Query Engine Affects Versions: 7.4 Reporter: Steven Hawkins Assignee: Steven Hawkins Priority: Critical Fix For: 7.4.1 When a plan can reuse the result buffer, for example with a top level sort operation. Then both the batchcollector and the processingnode may call close on the buffer. The second clause will trigger an assertionerror: java.lang.AssertionError: Assertion failed. at org.teiid.core.util.Assertion.failed(Assertion.java:73) at org.teiid.core.util.Assertion.assertTrue(Assertion.java:68) at org.teiid.core.util.Assertion.assertTrue(Assertion.java:60) at org.teiid.common.buffer.TupleBuffer.saveBatch(TupleBuffer.java:177) at org.teiid.common.buffer.TupleBuffer.close(TupleBuffer.java:192) at org.teiid.query.processor.BatchCollector.collectTuples(BatchCollector.java:153) at org.teiid.dqp.internal.process.RequestWorkItem.processMore(RequestWorkItem.java:352) at org.teiid.dqp.internal.process.RequestWorkItem.process(RequestWorkItem.java:278) at org.teiid.dqp.internal.process.AbstractWorkItem.run(AbstractWorkItem.java:49) at org.teiid.dqp.internal.process.RequestWorkItem.run(RequestWorkItem.java:207) at org.teiid.dqp.internal.process.DQPWorkContext.runInContext(DQPWorkContext.java:194) at org.teiid.dqp.internal.process.ThreadReuseExecutor$RunnableWrapper.run(ThreadReuseExecutor.java:118) at org.teiid.dqp.internal.process.ThreadReuseExecutor$3.run(ThreadReuseExecutor.java:288) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) at java.lang.Thread.run(Thread.java:636) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 4 months

4
11
0 / 0

[JBoss JIRA] Created: (TEIID-1518) Add a correlated subquery evaluation cache

by Steven Hawkins (JIRA)

Add a correlated subquery evaluation cache ------------------------------------------ Key: TEIID-1518 URL: https://issues.jboss.org/browse/TEIID-1518 Project: Teiid Issue Type: Feature Request Components: Query Engine Reporter: Steven Hawkins Assignee: Steven Hawkins The subquery aware evaluator should cache deterministic evaluations for reuse. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 4 months

3
2
0 / 0

[JBoss JIRA] (TEIID-1784) reserve batch accounting error

by Steven Hawkins (Created) (JIRA)

reserve batch accounting error ------------------------------ Key: TEIID-1784 URL: https://issues.jboss.org/browse/TEIID-1784 Project: Teiid Issue Type: Bug Components: Query Engine Affects Versions: 7.1.1 Reporter: Steven Hawkins Assignee: Steven Hawkins Under low memory conditions sortutility initial sort can claim and then not free buffer space. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 4 months

3
2
0 / 0

[JBoss JIRA] (TEIID-1822) Dynamically Defined Materialized Views

by Mark Addleman (Created) (JIRA)

Dynamically Defined Materialized Views -------------------------------------- Key: TEIID-1822 URL: https://issues.jboss.org/browse/TEIID-1822 Project: Teiid Issue Type: Feature Request Reporter: Mark Addleman Assignee: Steven Hawkins I'd like to be able to query a dynamically defined materialized view. For example, suppose I issue the query /* mat-view */ SELECT * FROM blah WHERE x='abc' Optionally (probably based on a hint), I'd like the following query to execute against the data set returned by the previous query rather than going back to the data source: /* use-mat-view */ SELECT * FROM (SELECT * FROM blah WHERE x='abc') GROUP BY a To make this truly useful, I'd like to define indexes. Something like: /* mat-view(index-on:a,b,c) */ SELECT * FROM blah WHERE x='abc' -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 4 months

6
9
0 / 0

[JBoss JIRA] (TEIID-1641) In org.teiid.jdbc.StatementImpl, as there have been no batched updates the batchedUpdates member hasn't been instantiated so clearBatch() throws a NPE.

by Steven Hawkins (Closed) (JIRA)

[ https://issues.jboss.org/browse/TEIID-1641?page=com.atlassian.jira.plugin... ] Steven Hawkins closed TEIID-1641. --------------------------------- > In org.teiid.jdbc.StatementImpl, as there have been no batched updates the batchedUpdates member hasn't been instantiated so clearBatch() throws a NPE. > -------------------------------------------------------------------------------------------------------------------------------------------------------- > > Key: TEIID-1641 > URL: https://issues.jboss.org/browse/TEIID-1641 > Project: Teiid > Issue Type: Bug > Components: JDBC Driver > Affects Versions: 7.4 > Reporter: Debbie Steigner > Priority: Blocker > Fix For: 7.4.1, 7.5 > > > In org.teiid.jdbc.StatementImpl, as there have been no batched updates the batchedUpdates member hasn't been instantiated so clearBatch() throws a NPE. > I have added a simple if (batchedUpdates != null) in clearBatch() on the Teiid 7.4 driver sources, please make this addition to EDS 5.2 driver. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 4 months

1
0
0 / 0

[JBoss JIRA] (TEIID-1791) Only the first 1000 items in the IN criteria are being pushed down in the query

by Steven Hawkins (Closed) (JIRA)

[ https://issues.jboss.org/browse/TEIID-1791?page=com.atlassian.jira.plugin... ] Steven Hawkins closed TEIID-1791. --------------------------------- > Only the first 1000 items in the IN criteria are being pushed down in the query > ------------------------------------------------------------------------------- > > Key: TEIID-1791 > URL: https://issues.jboss.org/browse/TEIID-1791 > Project: Teiid > Issue Type: Bug > Components: Query Engine > Affects Versions: 7.4.1 > Reporter: Debbie Steigner > Assignee: Steven Hawkins > Fix For: 7.4.1, 7.6 > > > In the below query, we are expecting a large number of book codes (46987), to be passed from ledgerbookid in t_sdm_ledgerbook into the TSL_FINANCIAL_ACCOUNT_ITEMS_T2 table. We can see from the query plan that it got the correct number of rows. > I understand that Oracle can only take 1000 items in an IN() construct, so EDS will split the criteria into multiple sets of 1000 IN criteria. I have seen this work previously. > It seems that for some reason in this query, possibly the other dependent join or hints, EDS pushes exactly 1000 criteria. Looking at the source specific SQL command in the EDS debug log, which I have attached, I counted the number of question marks in that IN() and it comes to 1000. We have checked that all of these book codes are unique, by doing a select distinct to the source model. > select cc.costcentreid, cc.description , ac.accountdescription, sum(func_amount) > from TSL_FINANCIAL_ACCOUNT_ITEMS_T2 tsl > join t_sdm_glaccount ac on tsl.account_code = ac.accountid > join /*+ MAKEIND */t_sdm_ledgerbook lb on tsl.book_code = lb.ledgerbookid > join /*+ MAKEIND */t_sdm_costcentre cc on lb.parentcostcentreid = cc.costcentreid > join /*+ MAKEIND */t_sdm_desk dsk on cc.parentdeskid = dsk.deskid > join /*+ MAKEIND */t_sdm_businessarea ba on dsk.parentbusinessareaid = ba.businessareaid > join /*+ MAKEIND */t_sdm_division div on ba.parentdivisionid = div.divisionid > where tsl.business_date = '2011-06-29' > and div.divisionid = 'GBM' > and ac.classificationid in (3,4) > group by cc.costcentreid, cc.description, ac.accountdescription; -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 4 months

1
0
0 / 0

[JBoss JIRA] Created: (TEIID-1645) SELECT COUNT(*) FROM VQT.Agg3 is expecting a result of 1 but 50 is being returned

by Warren Gibson (JIRA)

SELECT COUNT(*) FROM VQT.Agg3 is expecting a result of 1 but 50 is being returned --------------------------------------------------------------------------------- Key: TEIID-1645 URL: https://issues.jboss.org/browse/TEIID-1645 Project: Teiid Issue Type: Bug Components: Query Engine Affects Versions: 7.5 Reporter: Warren Gibson Assignee: Steven Hawkins Attachments: QT_MySql50_Push.vdb The VQT.Agg3 transformation is: SELECT COUNT(*)FROM BQT1.SmallA. BQT is expecting 1 to be returned but is getting 50. VDB attached. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 4 months

3
7
0 / 0

[JBoss JIRA] (TEIID-1816) Documentation changes for SSL configuration

by Paul Nittel (Created) (JIRA)

Documentation changes for SSL configuration ------------------------------------------- Key: TEIID-1816 URL: https://issues.jboss.org/browse/TEIID-1816 Project: Teiid Issue Type: Bug Components: Documentation Affects Versions: 7.4.1 Reporter: Paul Nittel Assignee: Steven Hawkins While testing SSL configuration I noticed a few items in the documentation which were confusing and in need of clarification. keymanagementAlgorithm - Type of key algorithm used. Default is based upon the VM, e.g. "SunX509" The out-of-the-box value of keymanagementAlgorithm is "false". If SunX509 is likely to be used, let's have it in teiid-jboss-beans.xml by default. The doc mentions the keystore "must be available in the classpath of Teiid Server." Apparently that's not just anywhere. I tried the lib directory and it failed. Ramesh suggested the conf directory and it worked. If it must be in conf, let's say so. Lastly, a minor nit. The second paragraph under section "3.5 Configuring SSL" is: There are three socket transports, each with it's own SSL configuration. Of course the word "it's" (a contraction of "it" and "is") should be replaced by the possessive form, "its". -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 4 months

9
9
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

teiid-issues November 2011