May 2009 - teiid-issues - Jboss List Archives

[JBoss JIRA] Commented: (TEIID-203) Make connector capabilites more granular.

by Steven Hawkins (JIRA)

[ https://jira.jboss.org/jira/browse/TEIID-203?page=com.atlassian.jira.plug... ] Steven Hawkins commented on TEIID-203: -------------------------------------- To support reference and multi-select picklists, the easiest path would be to check pushdown element metadata for searchability. A column should not be used in sort (distinct/non-all setquery/group by) unless it is marked as SEARCHABLE=SEARCHABLE|ALL_EXCEPT_LIKE. Reference and multi-select picklists would then be marked as SUPPORTS_LIKE, which would tell use not to pushdown operations that involve ordered comparisions, but we would allow = and <> since it is implied by like. > Make connector capabilites more granular. > ----------------------------------------- > > Key: TEIID-203 > URL: https://jira.jboss.org/jira/browse/TEIID-203 > Project: Teiid > Issue Type: Feature Request > Components: Connector API, Query Engine > Affects Versions: 6.0.0 > Reporter: John Doyle > Assignee: Steven Hawkins > Fix For: 6.1.0 > > > Some connector capabilites are only available in combination with others. For example, if you wish to support the SupportsAggregatesCount capability, you have to also support the SupportsAggregates capability(GROUP BY and HAVING). This requirement creates additional requirements for a connector where the source syustem cabilities do not correspond with the relationships we have defined between capabilites. > For instance, the SQL supported by salesforce can include the count(*) function, but it does not support GROUP BY or HAVING. Because we require c connector to support SupportsAggregates befrore it can support count(*), the connector is required to implement those functions if it wishes to pus down count(*). -- 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

1
0
0 / 0

[JBoss JIRA] Resolved: (TEIID-140) Unique constrainsts should be checked in costing logic

by Steven Hawkins (JIRA)

[ https://jira.jboss.org/jira/browse/TEIID-140?page=com.atlassian.jira.plug... ] Steven Hawkins resolved TEIID-140. ---------------------------------- Resolution: Rejected The metadata function used in cost calculation does return both the unique and primary keys. > Unique constrainsts should be checked in costing logic > ------------------------------------------------------ > > Key: TEIID-140 > URL: https://jira.jboss.org/jira/browse/TEIID-140 > Project: Teiid > Issue Type: Feature Request > Components: Query Engine > Affects Versions: 6.x > Reporter: Steven Hawkins > Priority: Optional > Fix For: 6.x > > > Defect Tracker #24750: Currently we only check primary key constraints in costing, however we should more generically check for uniqueness constraints. -- 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

1
0
0 / 0

[JBoss JIRA] Commented: (TEIID-244) Salesforce Connector should offer the abilty to query about object deletions.

by John Doyle (JIRA)

[ https://jira.jboss.org/jira/browse/TEIID-244?page=com.atlassian.jira.plug... ] John Doyle commented on TEIID-244: ---------------------------------- Also need to implement the queryAll operation. Over discussion with Mike Walker we've decided to implement it in the following manner. Every salesforce object has a IsDeleted column. This column only makes sense in the queryAll context; query will never object where isDeleted is true. We will override the isDeleted column using the default value property. If the isDeleted column is used as a paramter in the query, and the falue is "true' we will call queryAll; is the value is false, then we will use query. If it is not used as a parameter, we use the dafault value to make the same decision. > Salesforce Connector should offer the abilty to query about object deletions. > ----------------------------------------------------------------------------- > > Key: TEIID-244 > URL: https://jira.jboss.org/jira/browse/TEIID-244 > Project: Teiid > Issue Type: Feature Request > Components: Salesforce Connector > Affects Versions: 6.0.0 > Reporter: John Doyle > Assignee: John Doyle > Fix For: 6.1.0 > > > Genentech wants to materialize lots of SalesForce data in Oracle, to speed up their reporting query times. It makes a significant difference because SFDC does not support joins, whereas Oracle does. Wanting the best of both worlds, they also want the data to be as fresh as possible -- ideally, the mat views would be no more than 10 minutes out-of-sync with the live data. > The amount of data in SalesForce already takes 20+ minutes to cache, and it will slowly grow over time. So, the current materialization process will not meet the cache coherence (freshness) requirement, since the data will be stale by the time the staging table is populated and swapped in. > How would you speed it up? > .......response.... > I actually put together a custom materialization script > (attached,with doc and sample config file) for Credit Suisse for doing > these sorts of partial refreshes. It is Oracle-specific, but since > that is what you are doing too it should work for you too. > However, the use case at Credit Suisse was for doing these partial > refreshes nightly, with full refreshes done weekly. There is (just as > with our standard materialization scripts) a short period (when the > table names are being swapped) when the materialization won't be stable > (queries could fail or return unexpected results). I don't know if > that makes it not suitable for doing 10 minute refreshes. > I would recommend instead using the materialization only for historical > data (from overnight materialization run), and unioning it to the live > data for the newer stuff. That is, query SFDC only for data where > createdDate or LastModifiedDate = today, and union that with the > current data. Two issues you'd need to deal with in your logic: > -if the same record is retrieved from both sources (meaning it was an > existing record that had been modified today), the historical record > should be discarded in favor of the live one. > -deleted records - how to detect records that were deleted today? If > you could ask SFDC exactly what was deleted today that would be great, > but that is probably wishful thinking. So failing that you would need > to ask SFDC for the keys for all live records, and then discard from > the historical data any records with keys not on that list. Or, you > could just live with having the deleted records in the view for an > extra day... -- 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

1
0
0 / 0

[JBoss JIRA] Resolved: (TEIID-238) ENHANCEMENT: performance of non-pushed dependent set criteria

by Steven Hawkins (JIRA)

[ https://jira.jboss.org/jira/browse/TEIID-238?page=com.atlassian.jira.plug... ] Steven Hawkins resolved TEIID-238. ---------------------------------- Resolution: Done Added a check of the dependent value side - if it is less than 1/2 a batch then we'll materialize the values as a cached hashset, otherwise we'll simply return true and rely on the partitioned join logic to kick in if applicable. > ENHANCEMENT: performance of non-pushed dependent set criteria > ------------------------------------------------------------- > > Key: TEIID-238 > URL: https://jira.jboss.org/jira/browse/TEIID-238 > Project: Teiid > Issue Type: Feature Request > Components: Query Engine > Affects Versions: 6.0.0 > Reporter: Steven Hawkins > Assignee: Steven Hawkins > Fix For: 6.1.0 > > Original Estimate: 1 day > Remaining Estimate: 1 day > > Defect Tracker #24299: Dependent set criteria that is not pushed below an access node has potentially bad performance implications. These nodes should either be removed or the evaluation of set criteria should be changed so that it does not need to be based upon iteration (such as a cached set of values). -- 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

1
0
0 / 0

[JBoss JIRA] Created: (TEIID-541) Implement a partitioned merge join

by Steven Hawkins (JIRA)

Implement a partitioned merge join ---------------------------------- Key: TEIID-541 URL: https://jira.jboss.org/jira/browse/TEIID-541 Project: Teiid Issue Type: Feature Request Components: Query Engine Affects Versions: 6.0.0 Reporter: Steven Hawkins Assignee: Steven Hawkins Fix For: 6.1.0 To obviate the need for a hash join, we should have a scalable partitioned merge join. The smaller of the two join sides will be sorted and it's batch bounds used to partition the larger side rather than performing a full sort. -- 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

1
1
0 / 0

[JBoss JIRA] Created: (TEIID-545) add join expression distinct detection

by Steven Hawkins (JIRA)

add join expression distinct detection -------------------------------------- Key: TEIID-545 URL: https://jira.jboss.org/jira/browse/TEIID-545 Project: Teiid Issue Type: Feature Request Components: Query Engine Affects Versions: 6.0.0 Reporter: Steven Hawkins Assignee: Steven Hawkins Fix For: 6.1.0 for better join performance it would be good to know when the join expressions are unique. For pushdowns this can be obtained from the metadata otherwise the sortutility can be modified to detect uniqueness. -- 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

1
1
0 / 0

[JBoss JIRA] Created: (TEIID-544) NPE in Console In Runtime Panel, when secondary host is down

by Ramesh Reddy (JIRA)

NPE in Console In Runtime Panel, when secondary host is down ------------------------------------------------------------ Key: TEIID-544 URL: https://jira.jboss.org/jira/browse/TEIID-544 Project: Teiid Issue Type: Bug Affects Versions: 6.0.0 Reporter: Ramesh Reddy Priority: Minor Fix For: 6.1.0 java.lang.NullPointerException at com.metamatrix.platform.admin.api.runtime.ServiceData.equals(ServiceData.java:159) at java.util.HashMap.put(HashMap.java:376) at com.metamatrix.console.ui.views.runtime.model.RuntimeMgmtModel.createNode(RuntimeMgmtModel.java:171) at com.metamatrix.console.ui.views.runtime.model.RuntimeMgmtModel.addService(RuntimeMgmtModel.java:158) at com.metamatrix.console.ui.views.runtime.model.RuntimeMgmtModel.addProcess(RuntimeMgmtModel.java:123) at com.metamatrix.console.ui.views.runtime.model.RuntimeMgmtModel.addHost(RuntimeMgmtModel.java:107) at com.metamatrix.console.ui.views.runtime.model.RuntimeMgmtModel.refreshImpl(RuntimeMgmtModel.java:214) at com.metamatrix.console.ui.views.runtime.model.RuntimeMgmtModel.access$3(RuntimeMgmtModel.java:192) at com.metamatrix.console.ui.views.runtime.model.RuntimeMgmtModel$RefreshRunner.run(RuntimeMgmtModel.java:240) at java.util.TimerThread.mainLoop(Timer.java:512) at java.util.TimerThread.run(Timer.java:462) -- 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

1
1
0 / 0

[JBoss JIRA] Resolved: (TEIID-69) Fully implement Hash Join

by Steven Hawkins (JIRA)

[ https://jira.jboss.org/jira/browse/TEIID-69?page=com.atlassian.jira.plugi... ] Steven Hawkins resolved TEIID-69. --------------------------------- Resolution: Won't Fix A full implementation of hashjoin should not be needed, rather we'll rely on dependent joins and a partitioning optimization to merge join. > Fully implement Hash Join > ------------------------- > > Key: TEIID-69 > URL: https://jira.jboss.org/jira/browse/TEIID-69 > Project: Teiid > Issue Type: Bug > Components: Query Engine > Affects Versions: 6.x > Reporter: Steven Hawkins > Fix For: 7.x > > > Defect Tracker #24376: Based upon the old com.metamatrix.query.processor.relational.HashJoinStrategy (now deleted, but can be resurrectedfrom cvs) fully implement the hash join feature. Costing should be used in RuleChooseJoinStrategy to look for situations in which merge joins are valid but that have one side that is much smaller than the other (and preferable smaller than a processing batch). -- 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

1
0
0 / 0

[JBoss JIRA] Assigned: (TEIID-238) ENHANCEMENT: performance of non-pushed dependent set criteria

by Steven Hawkins (JIRA)

[ https://jira.jboss.org/jira/browse/TEIID-238?page=com.atlassian.jira.plug... ] Steven Hawkins reassigned TEIID-238: ------------------------------------ Assignee: Steven Hawkins > ENHANCEMENT: performance of non-pushed dependent set criteria > ------------------------------------------------------------- > > Key: TEIID-238 > URL: https://jira.jboss.org/jira/browse/TEIID-238 > Project: Teiid > Issue Type: Feature Request > Components: Query Engine > Affects Versions: 6.0.0 > Reporter: Steven Hawkins > Assignee: Steven Hawkins > Fix For: 6.1.0 > > Original Estimate: 1 day > Remaining Estimate: 1 day > > Defect Tracker #24299: Dependent set criteria that is not pushed below an access node has potentially bad performance implications. These nodes should either be removed or the evaluation of set criteria should be changed so that it does not need to be based upon iteration (such as a cached set of values). -- 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

1
0
0 / 0

[JBoss JIRA] Updated: (TEIID-238) ENHANCEMENT: performance of non-pushed dependent set criteria

by Steven Hawkins (JIRA)

[ https://jira.jboss.org/jira/browse/TEIID-238?page=com.atlassian.jira.plug... ] Steven Hawkins updated TEIID-238: --------------------------------- Fix Version/s: 6.1.0 (was: 6.2.0) > ENHANCEMENT: performance of non-pushed dependent set criteria > ------------------------------------------------------------- > > Key: TEIID-238 > URL: https://jira.jboss.org/jira/browse/TEIID-238 > Project: Teiid > Issue Type: Feature Request > Components: Query Engine > Affects Versions: 6.0.0 > Reporter: Steven Hawkins > Assignee: Steven Hawkins > Fix For: 6.1.0 > > Original Estimate: 1 day > Remaining Estimate: 1 day > > Defect Tracker #24299: Dependent set criteria that is not pushed below an access node has potentially bad performance implications. These nodes should either be removed or the evaluation of set criteria should be changed so that it does not need to be based upon iteration (such as a cached set of values). -- 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

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

teiid-issues May 2009