February 2009 - teiid-issues - Jboss List Archives

[JBoss JIRA] Created: (TEIID-354) Always create column aliases when there is a limit present.

by Steven Hawkins (JIRA)

Always create column aliases when there is a limit present. ----------------------------------------------------------- Key: TEIID-354 URL: https://jira.jboss.org/jira/browse/TEIID-354 Project: Teiid Issue Type: Sub-task Components: Connector API, Query Engine Affects Versions: 6.0.0 Reporter: Steven Hawkins Assignee: Steven Hawkins Fix For: 6.0.0 Currently connectors using inline views for limit must account for non-uniquely named output columns. This is a needless corner case that can be addressed by the query engine adding column aliases. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 10 months

1
1
0 / 0

[JBoss JIRA] Created: (TEIID-357) Create a cannonical set of push down functions

by Steven Hawkins (JIRA)

Create a cannonical set of push down functions ---------------------------------------------- Key: TEIID-357 URL: https://jira.jboss.org/jira/browse/TEIID-357 Project: Teiid Issue Type: Sub-task Components: Connector API, Query Engine Affects Versions: 6.0.0 Reporter: Steven Hawkins Assignee: Steven Hawkins Fix For: 6.0.0 Currently the engine may pushdown aliases of common functions (convert/cast, nvl/ifnull, lower/lcase, etc.) duplications should be removed by the rewriter to a canonical set defined by constants so that connector developers know what system functions to expect. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 10 months

1
1
0 / 0

[JBoss JIRA] Created: (TEIID-359) lpad and rpad implementation issues

by Steven Hawkins (JIRA)

lpad and rpad implementation issues ----------------------------------- Key: TEIID-359 URL: https://jira.jboss.org/jira/browse/TEIID-359 Project: Teiid Issue Type: Bug Components: Query Engine Affects Versions: 6.0.0 Reporter: Steven Hawkins Assignee: Steven Hawkins Priority: Minor Fix For: 6.0.0 lpad/rpad should -return a substring when the pad length is less than the string length -not return anything longer than max string length -accept a pad string of any length -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 10 months

1
1
0 / 0

[JBoss JIRA] Created: (TEIID-353) rewrite caseexpression as searchedcaseexpression and remove caseexpression from connector api

by Steven Hawkins (JIRA)

rewrite caseexpression as searchedcaseexpression and remove caseexpression from connector api --------------------------------------------------------------------------------------------- Key: TEIID-353 URL: https://jira.jboss.org/jira/browse/TEIID-353 Project: Teiid Issue Type: Sub-task Components: Connector API, Query Engine Affects Versions: 6.0.0 Reporter: Steven Hawkins Assignee: Steven Hawkins Fix For: 6.0.0 There is no instance of a connector supporting case, but not searched case - and we are already currently treating case a searched case in default translations. It would be best to cannonicalize and remove case expression altogether. The current rewrite for case expression is not correct either. Null values for case operands should not result in is null searched case criteria. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 10 months

1
1
0 / 0

[JBoss JIRA] Commented: (TEIID-168) Remove resultset caching

by Steven Hawkins (JIRA)

[ https://jira.jboss.org/jira/browse/TEIID-168?page=com.atlassian.jira.plug... ] Steven Hawkins commented on TEIID-168: -------------------------------------- Per VM is an initial design restriction based upon re-using the buffer manager logic. It is another line of work to re-implement the caching mechanisms of the buffer manager through jboss cache. I think you are overstating the case of limiting the usefulness. Caching relations (with scope determined by level of determinism) should have roughly the same performance curve with or without distribution. You would tend to just populate the caches faster with distribution. Along similar lines of thought, the case could be made for moving end user result set caching to the client vm. This defect should really only cover connector result set caching. > Remove resultset caching > ------------------------ > > Key: TEIID-168 > URL: https://jira.jboss.org/jira/browse/TEIID-168 > Project: Teiid > Issue Type: Feature Request > Components: JDBC Connector, Query Engine > Affects Versions: 6.x > Reporter: Steven Hawkins > Assignee: Steven Hawkins > Fix For: 6.1.0 > > > Resultset caching should be replaced with relation and procedure caching. This would initially be backed by the buffermanager, based upon hints/costing, and be utilized by the planner rather than the resolver. It would be good if we also detected the level of determinism. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 10 months

1
0
0 / 0

[JBoss JIRA] Commented: (TEIID-168) Remove resultset caching

by Greg Haber (JIRA)

[ https://jira.jboss.org/jira/browse/TEIID-168?page=com.atlassian.jira.plug... ] Greg Haber commented on TEIID-168: ---------------------------------- Thanks for the info. I think we are completely on the right track here by caching intermediate results rather than the end user result sets, but unfortunately I think that if the caching is done per-VM only that will greatly limit its usefulness (especially if the caching scope is the current session, rather than all sessions by that user to that VDB). Why? Because typically end users are not connecting directly to Teiid, but instead are connecting to it via a connection pool in their app server. And often these apps will release these connections back to the pool after completing each query (it would be expensive to hold on to pooled connections in a web-based app where it is not always possible to reliably detect user logout). So there is no guarantee that the same logical user will get the same connection from the pool, and since our connection logic randomly distributes connections among all the MMProcesses, this means that they are as likely to get a connection to a different JVM than they used for their previous query. A similar problem exists with apps that connect straight to MetaMatrix but that close connections after queries (or that only pool for a short time), such as connections coming in over ODBC via an ODBC-JDBC gateway mechanism as in the commerical JBEDSP product. So the usefulness of this caching mechanism will be limited to apps that use a legacy client-server type design where the client holds the connection open for an extended period of time - it won't help that much with modern multitier apps where the same logical user is likely to use several different sessions to MetaMatrix (potentially to different JVMs) in an application session. > Remove resultset caching > ------------------------ > > Key: TEIID-168 > URL: https://jira.jboss.org/jira/browse/TEIID-168 > Project: Teiid > Issue Type: Feature Request > Components: JDBC Connector, Query Engine > Affects Versions: 6.x > Reporter: Steven Hawkins > Assignee: Steven Hawkins > Fix For: 6.1.0 > > > Resultset caching should be replaced with relation and procedure caching. This would initially be backed by the buffermanager, based upon hints/costing, and be utilized by the planner rather than the resolver. It would be good if we also detected the level of determinism. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 10 months

1
0
0 / 0

[JBoss JIRA] Commented: (TEIID-285) Object Cache needs to be replaced with JBoss Cache

by Ramesh Reddy (JIRA)

[ https://jira.jboss.org/jira/browse/TEIID-285?page=com.atlassian.jira.plug... ] Ramesh Reddy commented on TEIID-285: ------------------------------------ As part of TEIID-168 this will be completely taken out in the favour of caching layer in the engine. Until TEIID-168 is fixed this will behave just like before. > Object Cache needs to be replaced with JBoss Cache > -------------------------------------------------- > > Key: TEIID-285 > URL: https://jira.jboss.org/jira/browse/TEIID-285 > Project: Teiid > Issue Type: Task > Components: Common > Affects Versions: 6.0.0 > Reporter: Ramesh Reddy > Assignee: Ramesh Reddy > Fix For: 6.0.0 > > > Currently home grown implementation of the Object Cache is used for result set caching and prepared plan caching etc. These needs to be backed by the JBoss Cache. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 10 months

1
0
0 / 0

[JBoss JIRA] Commented: (TEIID-168) Remove resultset caching

by Ramesh Reddy (JIRA)

[ https://jira.jboss.org/jira/browse/TEIID-168?page=com.atlassian.jira.plug... ] Ramesh Reddy commented on TEIID-168: ------------------------------------ As the description noted this will based upon the buffer manager, not on JBoss Cache. It will be be per VM, not distributed. The idea here is not to cache the end user result sets, but cache the intermediate results that are based on the source results based on design time hints. Thus effectively reproducing the user result set faster even in the case user has a modified query. Much like dynamic staging tables. > Remove resultset caching > ------------------------ > > Key: TEIID-168 > URL: https://jira.jboss.org/jira/browse/TEIID-168 > Project: Teiid > Issue Type: Feature Request > Components: JDBC Connector, Query Engine > Affects Versions: 6.x > Reporter: Steven Hawkins > Assignee: Steven Hawkins > Fix For: 6.1.0 > > > Resultset caching should be replaced with relation and procedure caching. This would initially be backed by the buffermanager, based upon hints/costing, and be utilized by the planner rather than the resolver. It would be good if we also detected the level of determinism. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 10 months

1
0
0 / 0

[JBoss JIRA] Work stopped: (TEIID-339) Push down aggragate and distinct through union

by Steven Hawkins (JIRA)

[ https://jira.jboss.org/jira/browse/TEIID-339?page=com.atlassian.jira.plug... ] Work on TEIID-339 stopped by Steven Hawkins. > Push down aggragate and distinct through union > ---------------------------------------------- > > Key: TEIID-339 > URL: https://jira.jboss.org/jira/browse/TEIID-339 > Project: Teiid > Issue Type: Task > Components: Query Engine > Affects Versions: 6.0.0 > Reporter: Li Liang > Assignee: Steven Hawkins > Fix For: 6.1.0 > > Original Estimate: 2 days > Remaining Estimate: 2 days > > This is related to case 6652 and case 6653. It improves performance to push down aggragate and distinct through union. If this is done before 5.5.3 release, we will consider pulling the logics back to 5.5.3. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 10 months

1
0
0 / 0

[JBoss JIRA] Commented: (TEIID-285) Object Cache needs to be replaced with JBoss Cache

by Greg Haber (JIRA)

[ https://jira.jboss.org/jira/browse/TEIID-285?page=com.atlassian.jira.plug... ] Greg Haber commented on TEIID-285: ---------------------------------- Now that Object Cache is backed by JBoss Cache, does that also mean that the cache is distributed across different JVMs in the same Teiid Server cluster, or is this per-JVM as with MetaMatrix 5.5.x? > Object Cache needs to be replaced with JBoss Cache > -------------------------------------------------- > > Key: TEIID-285 > URL: https://jira.jboss.org/jira/browse/TEIID-285 > Project: Teiid > Issue Type: Task > Components: Common > Affects Versions: 6.0.0 > Reporter: Ramesh Reddy > Assignee: Ramesh Reddy > Fix For: 6.0.0 > > > Currently home grown implementation of the Object Cache is used for result set caching and prepared plan caching etc. These needs to be backed by the JBoss Cache. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 10 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

teiid-issues February 2009