[JBoss JIRA] (TEIID-2555) Support pushdown of entire dependent joins
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-2555?page=com.atlassian.jira.plugin... ]
Work on TEIID-2555 started by Steven Hawkins.
> Support pushdown of entire dependent joins
> ------------------------------------------
>
> Key: TEIID-2555
> URL: https://issues.jboss.org/browse/TEIID-2555
> Project: Teiid
> Issue Type: Sub-task
> Components: Connector API, Query Engine
> Reporter: Steven Hawkins
> Assignee: Steven Hawkins
> Fix For: 8.5
>
>
> If the data volume is not too large then in many circumstances pushing down the entire independent side of the join to perform the entire join at the source can enhance performance.
> This would likely be built upon TEIID-2249 to make use of a make dep hint option. It would also likely be an expansion of the common table pushdown logic - but will require more extensive planning changes as the default logic is geared toward only the equi-join columns.
> It has also been requested that the default preference for pushdown be based upon the estimated data width.
> There is an issue with the form of the plan as with the existing logic it would be nearly impossible to back out of the decision to perform the full pushdown (which is why a hint is initially preferable).
> Marking the initial target at 8.5, but will likely slip.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 6 months
[JBoss JIRA] (TEIID-2559) Add additional make dep hint options
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-2559?page=com.atlassian.jira.plugin... ]
Steven Hawkins commented on TEIID-2559:
---------------------------------------
min/max have been added. leaving open for now though.
> Add additional make dep hint options
> ------------------------------------
>
> Key: TEIID-2559
> URL: https://issues.jboss.org/browse/TEIID-2559
> Project: Teiid
> Issue Type: Sub-task
> Components: Query Engine
> Reporter: Steven Hawkins
> Assignee: Steven Hawkins
> Fix For: 8.5
>
>
> make dep hints should support additional options to facilitate TEIID-2249. This includes:
> min - the minimum number of rows to trigger a dependent join full pushdown
> max - the maximum number of rows allowed before rejecting the dependent join (this would apply in both full pushdown and partial non-pushdown scenarios - in the latter though it will likely refer to the number of distinct values)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 6 months
[JBoss JIRA] (TEIID-2559) Add additional make dep hint options
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-2559?page=com.atlassian.jira.plugin... ]
Work on TEIID-2559 started by Steven Hawkins.
> Add additional make dep hint options
> ------------------------------------
>
> Key: TEIID-2559
> URL: https://issues.jboss.org/browse/TEIID-2559
> Project: Teiid
> Issue Type: Sub-task
> Components: Query Engine
> Reporter: Steven Hawkins
> Assignee: Steven Hawkins
> Fix For: 8.5
>
>
> make dep hints should support additional options to facilitate TEIID-2249. This includes:
> min - the minimum number of rows to trigger a dependent join full pushdown
> max - the maximum number of rows allowed before rejecting the dependent join (this would apply in both full pushdown and partial non-pushdown scenarios - in the latter though it will likely refer to the number of distinct values)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 6 months
[JBoss JIRA] (TEIID-2035) DeleteDataSource method on Admin API does not completely delete the Connection Factory
by Ramesh Reddy (JIRA)
[ https://issues.jboss.org/browse/TEIID-2035?page=com.atlassian.jira.plugin... ]
Ramesh Reddy edited comment on TEIID-2035 at 6/27/13 9:01 AM:
--------------------------------------------------------------
also what we have found out is if the server is recycled after the remove, then it works fine. It looks like when remove operation is done AS does not completely remove the services based on the previous ones, and trying to create the new services based on same names gets into creation issues.
I did not see the workaround text before, possibly we can implement that in the Admin api, not sure if that works
was (Author: rareddy):
also what we have found out is if the server is recycled after the remove, then it works fine. It looks like when remove operation is done AS does not completely remove the services based on the previous ones, and trying to create the new services based on same names gets into creation issues.
> DeleteDataSource method on Admin API does not completely delete the Connection Factory
> --------------------------------------------------------------------------------------
>
> Key: TEIID-2035
> URL: https://issues.jboss.org/browse/TEIID-2035
> Project: Teiid
> Issue Type: Bug
> Components: AdminApi
> Affects Versions: 8.0
> Reporter: Ramesh Reddy
> Assignee: Ramesh Reddy
>
> ConnectionFactory requires a two step creation process
> 1) create the resource-adaptor section
> 2) connection factory section
> The delete is removing the (2) and not (1). Thus any subsequent creates using the same name fails.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 6 months
[JBoss JIRA] (TEIID-2035) DeleteDataSource method on Admin API does not completely delete the Connection Factory
by Ramesh Reddy (JIRA)
[ https://issues.jboss.org/browse/TEIID-2035?page=com.atlassian.jira.plugin... ]
Ramesh Reddy commented on TEIID-2035:
-------------------------------------
also what we have found out is if the server is recycled after the remove, then it works fine. It looks like when remove operation is done AS does not completely remove the services based on the previous ones, and trying to create the new services based on same names gets into creation issues.
> DeleteDataSource method on Admin API does not completely delete the Connection Factory
> --------------------------------------------------------------------------------------
>
> Key: TEIID-2035
> URL: https://issues.jboss.org/browse/TEIID-2035
> Project: Teiid
> Issue Type: Bug
> Components: AdminApi
> Affects Versions: 8.0
> Reporter: Ramesh Reddy
> Assignee: Ramesh Reddy
>
> ConnectionFactory requires a two step creation process
> 1) create the resource-adaptor section
> 2) connection factory section
> The delete is removing the (2) and not (1). Thus any subsequent creates using the same name fails.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 6 months
[JBoss JIRA] (TEIID-2527) Dynamically change the sources in a multi-source model
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-2527?page=com.atlassian.jira.plugin... ]
Steven Hawkins commented on TEIID-2527:
---------------------------------------
The current assignToModel only works for existing sources and requires a model to be specified. When modifying a source however this is not correct. We want to ensure that all sources of the same name are updated regardless of which model they are associated with. I think it would be more clear to have three operations:
void removeSource(String vdbName, int vdbVersion, String modelName,
String sourceName)
throws AdminException;
To remove a source by name from the given model.
void addSource(String vdbName, int vdbVersion, String modelName,
String sourceName, String translatorName, String dsName)
throws AdminException;
Adds the source by name to the given model - if the source already exists somewhere else in the vdb, then the translator/dsName must match the existing. That's the same expectation at deployment time.
void updateSource(String vdbName, int vdbVersion, String sourceName,
String translatorName, String dsName) throws AdminException;
Basically the same as the current assignToModel only that modelName is no longer a parameter.
> Dynamically change the sources in a multi-source model
> ------------------------------------------------------
>
> Key: TEIID-2527
> URL: https://issues.jboss.org/browse/TEIID-2527
> Project: Teiid
> Issue Type: Feature Request
> Components: Query Engine, Server
> Reporter: Mark Addleman
> Assignee: Steven Hawkins
> Fix For: 8.5
>
>
> As a step toward a more dynamic VDB, it would be useful to allow data sources to be dynamically added/removed from a multi-source model. For more, see https://community.jboss.org/message/821113
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 6 months
[JBoss JIRA] (TEIID-2563) assignDataSource issues
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-2563?page=com.atlassian.jira.plugin... ]
Steven Hawkins resolved TEIID-2563.
-----------------------------------
Resolution: Done
updated the logic to always create a new connectormanger on a change (to ensure capabilities are regenerated, etc.) and only added after it's ready.
> assignDataSource issues
> -----------------------
>
> Key: TEIID-2563
> URL: https://issues.jboss.org/browse/TEIID-2563
> Project: Teiid
> Issue Type: Bug
> Components: Server
> Affects Versions: 7.4
> Reporter: Steven Hawkins
> Assignee: Steven Hawkins
> Fix For: 8.4.1, 8.5
>
>
> The assignDataSource admin operation has several issues
> - it uses different logic to create translator instances (which means that it cannot newly create delegating transaltors)
> - it adds new ConnectorManagers to the repository before they are valid (may have the wrong ExecutionFactory)
> - if the datasource is changes, the translator will stay same regardless of if it is being changed
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 6 months
[JBoss JIRA] (TEIID-2563) assignDataSource issues
by Steven Hawkins (JIRA)
Steven Hawkins created TEIID-2563:
-------------------------------------
Summary: assignDataSource issues
Key: TEIID-2563
URL: https://issues.jboss.org/browse/TEIID-2563
Project: Teiid
Issue Type: Bug
Components: Server
Affects Versions: 7.4
Reporter: Steven Hawkins
Assignee: Steven Hawkins
Fix For: 8.4.1, 8.5
The assignDataSource admin operation has several issues
- it uses different logic to create translator instances (which means that it cannot newly create delegating transaltors)
- it adds new ConnectorManagers to the repository before they are valid (may have the wrong ExecutionFactory)
- if the datasource is changes, the translator will stay same regardless of if it is being changed
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 6 months