August 2011 - teiid-issues - Jboss List Archives

[JBoss JIRA] Created: (TEIID-1706) JOIN between two text file data sources extremely slow

by Marc Shirley (JIRA)

JOIN between two text file data sources extremely slow ------------------------------------------------------ Key: TEIID-1706 URL: https://issues.jboss.org/browse/TEIID-1706 Project: Teiid Issue Type: Bug Components: Server Affects Versions: 7.4 Reporter: Marc Shirley Assignee: Steven Hawkins JOIN between two text files sources is extremely slow. Testing with 5MB files with around 35000 rows in each file resulted in a result set generation rate of about 100 rows/minute. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years

3
3
0 / 0

[JBoss JIRA] Resolved: (TEIID-1735) RF: Add the ability to use DISTINCT in windowed aggregates in EDS

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-1735?page=com.atlassian.jira.plugin... ] Steven Hawkins resolved TEIID-1735. ----------------------------------- Resolution: Done The ordered case seems like a moot point as Oracle/SQLServer/Postgresql do not support it, so just added support for distinct non-ordered aggs. Also added additional pushdown validation (could be applicable to 7.5, but is unlikely to matter except in corner cases) and added warnings from the capabilities converter if base supports are not present. > RF: Add the ability to use DISTINCT in windowed aggregates in EDS > ----------------------------------------------------------------- > > Key: TEIID-1735 > URL: https://issues.jboss.org/browse/TEIID-1735 > Project: Teiid > Issue Type: Feature Request > Components: Query Engine > Affects Versions: 7.5 > Reporter: Debbie Steigner > Assignee: Steven Hawkins > Fix For: 7.6 > > > According to the following page: http://docs.jboss.org/teiid/7.5.0.Final/reference/en-US/html_single/#wind... > This states that "windowed aggregates may not use DISTINCT". I would like to request that use of DISTINCT in aggregate functions be supported in a future release. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 1 month

1
0
0 / 0

[JBoss JIRA] Updated: (TEIID-1735) RF: Add the ability to use DISTINCT in windowed aggregates in EDS

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-1735?page=com.atlassian.jira.plugin... ] Steven Hawkins updated TEIID-1735: ---------------------------------- Fix Version/s: 7.6 Affects Version/s: 7.5 This restriction was made because both SQL Server and Postgres lack support. We can add support in Teiid with an additional capability check. The existing logic would need adapted to handle distinct ordered over clauses as performing a full pass sort would be too expensive. > RF: Add the ability to use DISTINCT in windowed aggregates in EDS > ----------------------------------------------------------------- > > Key: TEIID-1735 > URL: https://issues.jboss.org/browse/TEIID-1735 > Project: Teiid > Issue Type: Feature Request > Components: Query Engine > Affects Versions: 7.5 > Reporter: Debbie Steigner > Assignee: Steven Hawkins > Fix For: 7.6 > > > According to the following page: http://docs.jboss.org/teiid/7.5.0.Final/reference/en-US/html_single/#wind... > This states that "windowed aggregates may not use DISTINCT". I would like to request that use of DISTINCT in aggregate functions be supported in a future release. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 1 month

1
0
0 / 0

[JBoss JIRA] Assigned: (TEIID-1735) RF: Add the ability to use DISTINCT in windowed aggregates in EDS

by Van Halbert (JIRA)

[ https://issues.jboss.org/browse/TEIID-1735?page=com.atlassian.jira.plugin... ] Van Halbert reassigned TEIID-1735: ---------------------------------- Assignee: Steven Hawkins (was: Van Halbert) > RF: Add the ability to use DISTINCT in windowed aggregates in EDS > ----------------------------------------------------------------- > > Key: TEIID-1735 > URL: https://issues.jboss.org/browse/TEIID-1735 > Project: Teiid > Issue Type: Feature Request > Components: Query Engine > Reporter: Debbie Steigner > Assignee: Steven Hawkins > > According to the following page: http://docs.jboss.org/teiid/7.5.0.Final/reference/en-US/html_single/#wind... > This states that "windowed aggregates may not use DISTINCT". I would like to request that use of DISTINCT in aggregate functions be supported in a future release. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 1 month

1
0
0 / 0

[JBoss JIRA] Moved: (TEIID-1735) RF: Add the ability to use DISTINCT in windowed aggregates in EDS

by Van Halbert (JIRA)

[ https://issues.jboss.org/browse/TEIID-1735?page=com.atlassian.jira.plugin... ] Van Halbert moved SOA-3326 to TEIID-1735: ----------------------------------------- Project: Teiid (was: JBoss Enterprise SOA Platform) Key: TEIID-1735 (was: SOA-3326) Component/s: Query Engine (was: EDS) Security: (was: Public) > RF: Add the ability to use DISTINCT in windowed aggregates in EDS > ----------------------------------------------------------------- > > Key: TEIID-1735 > URL: https://issues.jboss.org/browse/TEIID-1735 > Project: Teiid > Issue Type: Feature Request > Components: Query Engine > Reporter: Debbie Steigner > Assignee: Van Halbert > > According to the following page: http://docs.jboss.org/teiid/7.5.0.Final/reference/en-US/html_single/#wind... > This states that "windowed aggregates may not use DISTINCT". I would like to request that use of DISTINCT in aggregate functions be supported in a future release. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 1 month

1
0
0 / 0

[JBoss JIRA] Created: (TEIID-1734) CLONE - Update the Salesforce translator to the latest API, version 22

by Mark Drilling (JIRA)

CLONE - Update the Salesforce translator to the latest API, version 22 ---------------------------------------------------------------------- Key: TEIID-1734 URL: https://issues.jboss.org/browse/TEIID-1734 Project: Teiid Issue Type: Feature Request Components: Connector API Affects Versions: 7.4 Reporter: Mark Drilling Assignee: Ramesh Reddy The salesforce translator is currently on V17 of the API. It should be upgraded to the latest (currently V22). -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 1 month

1
0
0 / 0

[JBoss JIRA] Resolved: (TEIID-142) Introduce a mechanism to allow single source updates without an xa txn.

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-142?page=com.atlassian.jira.plugin.... ] Steven Hawkins resolved TEIID-142. ---------------------------------- Fix Version/s: (was: 9.0) Resolution: Out of Date I'm going to mark this issue as out of date. See http://community.jboss.org/wiki/Multiple1PC for resolutions when using one or more 1PC resources under a transaction. There is still an issue here, which would be to specifically force non-XA behavior for performance - such as 1PC cross source read / write or multiple reads/updates (which could be something like "BEGIN ATOMIC <translator name>") to the same source in a procedure. An issue along those lines can be logged when needed. > Introduce a mechanism to allow single source updates without an xa txn. > ----------------------------------------------------------------------- > > Key: TEIID-142 > URL: https://issues.jboss.org/browse/TEIID-142 > Project: Teiid > Issue Type: Feature Request > Components: Query Engine > Affects Versions: 9.x > Reporter: Steven Hawkins > Priority: Minor > > Defect Tracker #24910: txnAutoWrap = OFF in 5.5 disables the use of local transactions. This was primarily done to support customers who 1. weren't paying for the transactional product > 2. weren't using an XA connection for an update > The concern of 1 goes away in 5.6 as all customers will have a transactional product. The secondary concern requires either a connection property that either ignores autocommit or the generic support of 1 phase commit on connectors supporting update and local transactions. The latter solution would allow non-XA aware connectors to seem XA aware as long as all updates went to a single source. Arjuna would also need to be configured to support the one phase commit optimization. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 1 month

1
0
0 / 0

[JBoss JIRA] Resolved: (TEIID-139) Enhancement: Language support for transactions

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-139?page=com.atlassian.jira.plugin.... ] Steven Hawkins resolved TEIID-139. ---------------------------------- Fix Version/s: 7.6 (was: 9.x) Resolution: Duplicate Issue JDBC/ODBC (start transaction) and virtual procedures (begin atomic) all have support for transaction statements. Marking as a dup of TEIID-1701 > Enhancement: Language support for transactions > ---------------------------------------------- > > Key: TEIID-139 > URL: https://issues.jboss.org/browse/TEIID-139 > Project: Teiid > Issue Type: Feature Request > Components: Query Engine > Affects Versions: 7.0 > Reporter: Steven Hawkins > Priority: Optional > Fix For: 7.6 > > > Defect Tracker #20222: Supporting a limited transaction syntax, possibly similar to http://dev.mysql.com/doc/refman/4.1/en/commit.html, would allow the writers of virtual stored procedures to have declarative transaction handling rather than being forced to use the same transaction settings for all procedures based upon connection properties. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 1 month

1
0
0 / 0

[JBoss JIRA] Updated: (TEIID-139) Enhancement: Language support for transactions

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-139?page=com.atlassian.jira.plugin.... ] Steven Hawkins updated TEIID-139: --------------------------------- Affects Version/s: 7.0 (was: 9.x) > Enhancement: Language support for transactions > ---------------------------------------------- > > Key: TEIID-139 > URL: https://issues.jboss.org/browse/TEIID-139 > Project: Teiid > Issue Type: Feature Request > Components: Query Engine > Affects Versions: 7.0 > Reporter: Steven Hawkins > Priority: Optional > Fix For: 9.x > > > Defect Tracker #20222: Supporting a limited transaction syntax, possibly similar to http://dev.mysql.com/doc/refman/4.1/en/commit.html, would allow the writers of virtual stored procedures to have declarative transaction handling rather than being forced to use the same transaction settings for all procedures based upon connection properties. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 1 month

1
0
0 / 0

[JBoss JIRA] Issue Comment Edited: (TEIID-1726) Requesting ability to add/use Oracle hints in EDS

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-1726?page=com.atlassian.jira.plugin... ] Steven Hawkins edited comment on TEIID-1726 at 8/29/11 4:45 PM: ---------------------------------------------------------------- based on your comments the refined set of options are: - targeted use of native query features, see TEIID-669. Now that designer has flexible extension metadata, its quite easy for us to add handling for source procedures/views where the native sql is defined in designer. However any hints in the sql would always be applied and not contextually. Exposing source procedures allowing for dynamic sql (like what is done for MDX) could also be done, but that breaks all abstraction and would not integrate well. - add support for the multi-hint comment container (alternative option #2 above). Unless some other syntax was used to separate the hints, a parsing change would be needed to support nested comments (see below). And without additional considerations, this would be non-positional in the source sql, so it really only applies to Oracle style hints. SQL Server, db2, mysql, Teiid, etc. make use of positional/syntax related hints. Referencing columns/tables as they appear in the user query would also add difficulty since we would have to introduce some escape syntax then parse/update the hint once the source query is planned - e.g. SELECT /\*+ sh my-oracle:/\*+LEADING(@BAL@) ALL_ROWS\*/ \*/ ... - implement TEIID handling for LEADING/ALL_ROWS (although the specifics of how tables/views are referenced would take more thought) as they are relevant for EDS queries (although our latency/processing tradeoff in union processing is fairly effective), and add pushdown propagation for the hints. As you point out this of course lacks generality. - instead of using Java to customize translators, make use of something akin to DB2 optimization profiles, which has some tie in to alternative option #2/#3. The translator could be configured with a file that describes hint application. The most simplistic rules could just match the entire query or be regular expression matching the source query, e.g.: <rule match="SELECT (.\*) FROM BAL (.\*) UNION SELECT (.\*)" replace="SELECT /\*+ALL_ROWS\*/ $1 FROM BAL $2 UNION SELECT $3"/> The tie to #2/#3 would be to take advantage of additional metadata / and or allow for the user to drive the hint application: <rule user_hint="loop" match="INNER JOIN" replace="INNER LOOP JOIN"/> which could handle simplistic application of SQL Server loop join hints (assuming that the translator was configured to expect ANSI FROM clauses), e.g.: SELECT /\*+ sh my-ssql:/+\*loop\*/ \*/ ... The benefit here is that this doesn't require breaking any abstraction and can be done on an as needed basis without modifying vdbs or the client application, but it could be brittle and there are still a lot of details left out here, such as rule precedence, rule file format, etc. was (Author: shawkins): based on your comments the refined set of options are: - targeted use of native query features, see TEIID-669. Now that designer has flexible extension metadata, its quite easy for us to add handling for source procedures/views where the native sql is defined in designer. However any hints in the sql would always be applied and not contextually. Exposing source procedures allowing for dynamic sql (like what is done for MDX) could also be done, but that breaks all abstraction and would not integrate well. - add support for the multi-hint comment container (alternative option #2 above). Unless some other syntax was used to separate the hints, a parsing change would be needed to support nested comments (see below). And without additional considerations, this would be non-positional in the source sql, so it really only applies to Oracle style hints. SQL Server, db2, mysql, Teiid, etc. make use of positional/syntax related hints. Referencing columns/tables as they appear in the user query would also add difficulty since we would have to introduce some escape syntax then parse/update the hint once the source query is planned - e.g. SELECT /*+ sh my-oracle:/*+LEADING(@BAL@) ALL_ROWS*/ */ ... - implement TEIID handling for LEADING/ALL_ROWS (although the specifics of how tables/views are referenced would take more thought) as they are relevant for EDS queries (although our latency/processing tradeoff in union processing is fairly effective), and add pushdown propagation for the hints. As you point out this of course lacks generality. - instead of using Java to customize translators, make use of something akin to DB2 optimization profiles, which has some tie in to alternative option #2/#3. The translator could be configured with a file that describes hint application. The most simplistic rules could just match the entire query or be regular expression matching the source query, e.g.: <rule match="SELECT (.*) FROM BAL (.*) UNION SELECT (.*)" replace="SELECT /*+ALL_ROWS+/ $1 FROM BAL $2 UNION SELECT $3"/> The tie to #2/#3 would be to take advantage of additional metadata / and or allow for the user to drive the hint application: <rule user_hint="loop" match="INNER JOIN" replace="INNER LOOP JOIN"/> which could handle simplistic application of SQL Server loop join hints (assuming that the translator was configured to expect ANSI FROM clauses), e.g.: SELECT /*+ sh my-ssql:/+*loop*/ */ ... The benefit here is that this doesn't require breaking any abstraction and can be done on an as needed basis without modifying vdbs or the client application, but it could be brittle and there are still a lot of details left out here, such as rule precedence, rule file format, etc. > Requesting ability to add/use Oracle hints in EDS > ------------------------------------------------- > > Key: TEIID-1726 > URL: https://issues.jboss.org/browse/TEIID-1726 > Project: Teiid > Issue Type: Feature Request > Components: Server > Affects Versions: 7.4.1 > Reporter: Debbie Steigner > > Requesting the ability to use Oracle hints inside virtual transformations and enduser queries in EDS and Teiid Designer -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 1 month

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

teiid-issues August 2011