[JBoss JIRA] Created: (TEIID-1374) Nested correlated reference issue with rewritten queries
by Steven Hawkins (JIRA)
Nested correlated reference issue with rewritten queries
--------------------------------------------------------
Key: TEIID-1374
URL: https://jira.jboss.org/browse/TEIID-1374
Project: Teiid
Issue Type: Bug
Components: Query Engine
Affects Versions: 7.0
Reporter: Steven Hawkins
Assignee: Steven Hawkins
In a query such as "select * from bqt1.smalla where exists (select intnum from bqt1.smalla x where smalla.intnum = x.intnum and exists (select intnum from bqt1.smalla where exists (select intnum from bqt1.smalla x where smalla.intnum = x.intnum)))" we will inappropriately report that the top exists subquery has 2 correlated references since we see the more deeply nested smalla.intnum also.
This is generally not a issue, it can introduce errors in places where subqueries are rewritten, such as with subquery optimization or inherently updatable view queries.
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 1 month
[JBoss JIRA] Created: (TEIID-1598) translator scoped result set caching
by Mark Addleman (JIRA)
translator scoped result set caching
------------------------------------
Key: TEIID-1598
URL: https://issues.jboss.org/browse/TEIID-1598
Project: Teiid
Issue Type: Feature Request
Reporter: Mark Addleman
Assignee: Steven Hawkins
Priority: Minor
Something Steven mentioned in Teiid-1589 got me thinking: It would be helpful for individual translators to request that Teiid cache results sets that match the query as presented to the execution factory (after the planner is done rewriting the query based on the translator's capabilities).
I envision a new method on an Execution getCacheTtlMs() where zero or negative indicates that Teiid shouldn't cache the results.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 1 month
[JBoss JIRA] Created: (TEIID-1600) Exact numerical literal parsing
by Steven Hawkins (JIRA)
Exact numerical literal parsing
-------------------------------
Key: TEIID-1600
URL: https://issues.jboss.org/browse/TEIID-1600
Project: Teiid
Issue Type: Bug
Components: Query Engine
Reporter: Steven Hawkins
Assignee: Steven Hawkins
Fix For: 8.0
Teiid diverges from the SQL spec by parsing numerical expressions of the form <integral value>.<integral value> as doubles rather than as an exact numeric type (which for us would be BigDecimal). I believe this was originally done to match Java parsing semantics and potentially to avoid performance overhead of using BigBecimal. However this can lead to a loss of precision that is not expected by ANSI SQL.
inexact numeric values entered in scientific notation would not be affected by this change. They would still be parsed as doubles.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 1 month
[JBoss JIRA] Created: (TEIID-1131) Document/expand sequence support
by Steve Hawkins (JIRA)
Document/expand sequence support
--------------------------------
Key: TEIID-1131
URL: https://jira.jboss.org/browse/TEIID-1131
Project: Teiid
Issue Type: Feature Request
Components: JDBC Connector, Query Engine
Affects Versions: 7.0
Reporter: Steve Hawkins
Assignee: Steve Hawkins
Fix For: 7.1
Currently sequence workaround logic only exists for oracle and is undocumented. We should look at expanding sequence support - even for dynamic vdbs, see SQuriel's handling of system queries for retrieving sequence metadata.
At least allowing the workaround logic to work for all sources that support sequences (Postgres, DB2, etc.) would be good.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 1 month
[JBoss JIRA] Created: (TEIID-1543) Add a query hint to limit the number of concurrent source queries
by Steven Hawkins (JIRA)
Add a query hint to limit the number of concurrent source queries
-----------------------------------------------------------------
Key: TEIID-1543
URL: https://issues.jboss.org/browse/TEIID-1543
Project: Teiid
Issue Type: Sub-task
Components: Query Engine
Affects Versions: 7.4
Reporter: Steven Hawkins
Assignee: Steven Hawkins
We would like a new query hint to limit the number of parallel executions of union members. This is useful in two situations:
1. When the queries are expensive, but the overall union contains a limit that is most likely to be fulfilled by the first member of the union
2. When the queries are backed by a common resource which may be overloaded by multiple queries
The addition of a hint would make this manageable by the client; perhaps something like "/*+ parallel=2*/"?
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 2 months
[JBoss JIRA] Created: (TEIID-1248) Clob usability
by Steven Hawkins (JIRA)
Clob usability
--------------
Key: TEIID-1248
URL: https://jira.jboss.org/browse/TEIID-1248
Project: Teiid
Issue Type: Feature Request
Components: Query Engine
Affects Versions: 8.0
Reporter: Steven Hawkins
Assignee: Steven Hawkins
Priority: Minor
Fix For: 8.0
In many circumstances, clobs should be treated as charsequences to allow for use in string functions (concat returning clob, insert, left, etc.).
There have also been customer requests to treat clobs as comparable, but that there are a lot of places including at design time where we validate against clobs being comparable that it may not be a good idea.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 2 months