[JBoss JIRA] Moved: (TEIID-954) Need method to controll max amount of bufer disk space
by Van Halbert (JIRA)
[ https://jira.jboss.org/jira/browse/TEIID-954?page=com.atlassian.jira.plug... ]
Van Halbert moved JBEDSP-1154 to TEIID-954:
-------------------------------------------
Project: Teiid (was: JBoss Enterprise Data Services Platform)
Key: TEIID-954 (was: JBEDSP-1154)
Component/s: Query Engine
(was: Server)
(was: Query)
Fix Version/s: (was: Westport)
Affects Version/s: (was: 5.5)
> Need method to controll max amount of bufer disk space
> ------------------------------------------------------
>
> Key: TEIID-954
> URL: https://jira.jboss.org/jira/browse/TEIID-954
> Project: Teiid
> Issue Type: Bug
> Components: Query Engine
> Reporter: Steven Hawkins
>
> There needs to be a configurable limit to how much disk space buffer manager is able to use.
> Currently, you can specify the limit per file and the limit of how many files buffer manager can have open at one time, but there is no means of keeping buffer manager for eating up all the available disk space and then resulting in unpredictable behavior and stability.
> It's fine if queries that need the file buffer manager but find it is full fail outright when it is full.
--
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
14 years, 2 months
[JBoss JIRA] Resolved: (TEIID-949) Criteria on constant column with aggregate function doesn't push criteria down correctly
by Steven Hawkins (JIRA)
[ https://jira.jboss.org/jira/browse/TEIID-949?page=com.atlassian.jira.plug... ]
Steven Hawkins resolved TEIID-949.
----------------------------------
Resolution: Done
Added a check in RulePushSelectCriteria to prevent this case.
> Criteria on constant column with aggregate function doesn't push criteria down correctly
> ----------------------------------------------------------------------------------------
>
> Key: TEIID-949
> URL: https://jira.jboss.org/jira/browse/TEIID-949
> Project: Teiid
> Issue Type: Bug
> Components: Query Engine
> Affects Versions: 6.0.0
> Environment: MM5.5.4
> Reporter: Larry O'Leary
> Assignee: Steven Hawkins
> Fix For: 7.0
>
>
> When a column value is a constant and used along with an aggregate, criteria on the constant column is being ignored. Here is an example query:
> SELECT * FROM (
> SELECT b.count, enterprise_id FROM (
> SELECT COUNT(*), 35 AS enterprise_id FROM (
> SELECT "A Name" AS Name, 37 AS enterprise_id
> ) c
> ) b
> ) a WHERE enterprise_id = 1 OPTION DEBUG
> The expected result is an empty result set. Instead, the result set comes back as:
> COUNT, ENTERPRISE_ID
> 0, 35
> The resulting plan looks like:
> OPTIMIZATION COMPLETE:
> PLAN TREE:
> (type=Relational, command=SELECT * FROM (SELECT b."count", enterprise_id FROM (SELECT COUNT(*), 35 AS enterprise_id FROM (SELECT 'A Name' AS Name, 37 AS enterprise_id) AS c) AS b) AS a WHERE enterprise_id = 1 OPTION DEBUG, props={0=PlanHints})
> canonical plan:
> Project(groups=[b], props={90=[b."count", enterprise_id], 30=[b."count", enterprise_id], 114=0.0, 91=[A."COUNT", A.ENTERPRISE_ID]})
> Source(groups=[b], props={90=[b."count", enterprise_id], 64=SELECT COUNT(*), 35 AS enterprise_id FROM (SELECT 'A Name' AS Name, 37 AS enterprise_id) AS c, 114=0.0, 60={b."count"=COUNT(*), b.enterprise_id=35}})
> Project(groups=[], props={90=[b."count", enterprise_id], 30=[COUNT(*), 35 AS enterprise_id], 114=0.0, 60={b."count"=COUNT(*), b.enterprise_id=35}, 91=[COUNT(*), 35 AS enterprise_id]})
> Group(groups=[c], props={90=[COUNT(*)], 114=0.0, 81=[COUNT(*)]})
> Null(groups=[c], props={90=[], 114=0.0})
> PROCESSOR PLAN:
> ProjectNode(1) output=[b."count", enterprise_id] [b."count", enterprise_id]
> ProjectNode(2) output=[b."count", enterprise_id] [COUNT(*), 35 AS enterprise_id]
> GroupingNode(3) output=[COUNT(*)] null
> NullNode(4) output=[]
> If the query is changed as follows, the expected result is received:
> SELECT * FROM (
> SELECT b.count, enterprise_id FROM (
> SELECT COUNT(*), 35 AS enterprise_id FROM (
> SELECT "A Name" AS Name, 37 AS enterprise_id
> ) c GROUP BY enterprise_id
> ) b
> ) a WHERE enterprise_id = 1 OPTION DEBUG
> Which yields a very similar plan:
> PLAN TREE:
> (type=Relational, command=SELECT * FROM (SELECT b."count", enterprise_id FROM (SELECT COUNT(*), 35 AS enterprise_id FROM (SELECT 'A Name' AS Name, 37 AS enterprise_id) AS c GROUP BY enterprise_id) AS b) AS a WHERE enterprise_id = 1 OPTION DEBUG, props={0=PlanHints})
> canonical plan:
> Project(groups=[b], props={90=[b."count", enterprise_id], 30=[b."count", enterprise_id], 114=0.0, 91=[A."COUNT", A.ENTERPRISE_ID]})
> Source(groups=[b], props={90=[b."count", enterprise_id], 64=SELECT COUNT(*), 35 AS enterprise_id FROM (SELECT 'A Name' AS Name, 37 AS enterprise_id) AS c GROUP BY enterprise_id, 114=0.0, 60={b."count"=COUNT(*), b.enterprise_id=35}})
> Project(groups=[], props={90=[b."count", enterprise_id], 30=[COUNT(*), 35 AS enterprise_id], 114=0.0, 60={b."count"=COUNT(*), b.enterprise_id=35}, 91=[COUNT(*), 35 AS enterprise_id]})
> Group(groups=[c], props={90=[COUNT(*)], 114=0.0, 80=[enterprise_id], 81=[COUNT(*)]})
> Null(groups=[c], props={90=[enterprise_id], 114=0.0})
> PROCESSOR PLAN:
> ProjectNode(1) output=[b."count", enterprise_id] [b."count", enterprise_id]
> ProjectNode(2) output=[b."count", enterprise_id] [COUNT(*), 35 AS enterprise_id]
> GroupingNode(3) output=[COUNT(*)] [enterprise_id]
> NullNode(4) output=[enterprise_id]
> Except the NullNode node contains enterprise_id as its target column vs an empty value.
--
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
14 years, 2 months
[JBoss JIRA] Updated: (TEIID-949) Criteria on constant column with aggregate function doesn't push criteria down correctly
by Steven Hawkins (JIRA)
[ https://jira.jboss.org/jira/browse/TEIID-949?page=com.atlassian.jira.plug... ]
Steven Hawkins updated TEIID-949:
---------------------------------
Fix Version/s: 7.0
Affects Version/s: 6.0.0
(was: 7.0)
Assignee: Steven Hawkins (was: Larry O'Leary)
> Criteria on constant column with aggregate function doesn't push criteria down correctly
> ----------------------------------------------------------------------------------------
>
> Key: TEIID-949
> URL: https://jira.jboss.org/jira/browse/TEIID-949
> Project: Teiid
> Issue Type: Bug
> Components: Query Engine
> Affects Versions: 6.0.0
> Environment: MM5.5.4
> Reporter: Larry O'Leary
> Assignee: Steven Hawkins
> Fix For: 7.0
>
>
> When a column value is a constant and used along with an aggregate, criteria on the constant column is being ignored. Here is an example query:
> SELECT * FROM (
> SELECT b.count, enterprise_id FROM (
> SELECT COUNT(*), 35 AS enterprise_id FROM (
> SELECT "A Name" AS Name, 37 AS enterprise_id
> ) c
> ) b
> ) a WHERE enterprise_id = 1 OPTION DEBUG
> The expected result is an empty result set. Instead, the result set comes back as:
> COUNT, ENTERPRISE_ID
> 0, 35
> The resulting plan looks like:
> OPTIMIZATION COMPLETE:
> PLAN TREE:
> (type=Relational, command=SELECT * FROM (SELECT b."count", enterprise_id FROM (SELECT COUNT(*), 35 AS enterprise_id FROM (SELECT 'A Name' AS Name, 37 AS enterprise_id) AS c) AS b) AS a WHERE enterprise_id = 1 OPTION DEBUG, props={0=PlanHints})
> canonical plan:
> Project(groups=[b], props={90=[b."count", enterprise_id], 30=[b."count", enterprise_id], 114=0.0, 91=[A."COUNT", A.ENTERPRISE_ID]})
> Source(groups=[b], props={90=[b."count", enterprise_id], 64=SELECT COUNT(*), 35 AS enterprise_id FROM (SELECT 'A Name' AS Name, 37 AS enterprise_id) AS c, 114=0.0, 60={b."count"=COUNT(*), b.enterprise_id=35}})
> Project(groups=[], props={90=[b."count", enterprise_id], 30=[COUNT(*), 35 AS enterprise_id], 114=0.0, 60={b."count"=COUNT(*), b.enterprise_id=35}, 91=[COUNT(*), 35 AS enterprise_id]})
> Group(groups=[c], props={90=[COUNT(*)], 114=0.0, 81=[COUNT(*)]})
> Null(groups=[c], props={90=[], 114=0.0})
> PROCESSOR PLAN:
> ProjectNode(1) output=[b."count", enterprise_id] [b."count", enterprise_id]
> ProjectNode(2) output=[b."count", enterprise_id] [COUNT(*), 35 AS enterprise_id]
> GroupingNode(3) output=[COUNT(*)] null
> NullNode(4) output=[]
> If the query is changed as follows, the expected result is received:
> SELECT * FROM (
> SELECT b.count, enterprise_id FROM (
> SELECT COUNT(*), 35 AS enterprise_id FROM (
> SELECT "A Name" AS Name, 37 AS enterprise_id
> ) c GROUP BY enterprise_id
> ) b
> ) a WHERE enterprise_id = 1 OPTION DEBUG
> Which yields a very similar plan:
> PLAN TREE:
> (type=Relational, command=SELECT * FROM (SELECT b."count", enterprise_id FROM (SELECT COUNT(*), 35 AS enterprise_id FROM (SELECT 'A Name' AS Name, 37 AS enterprise_id) AS c GROUP BY enterprise_id) AS b) AS a WHERE enterprise_id = 1 OPTION DEBUG, props={0=PlanHints})
> canonical plan:
> Project(groups=[b], props={90=[b."count", enterprise_id], 30=[b."count", enterprise_id], 114=0.0, 91=[A."COUNT", A.ENTERPRISE_ID]})
> Source(groups=[b], props={90=[b."count", enterprise_id], 64=SELECT COUNT(*), 35 AS enterprise_id FROM (SELECT 'A Name' AS Name, 37 AS enterprise_id) AS c GROUP BY enterprise_id, 114=0.0, 60={b."count"=COUNT(*), b.enterprise_id=35}})
> Project(groups=[], props={90=[b."count", enterprise_id], 30=[COUNT(*), 35 AS enterprise_id], 114=0.0, 60={b."count"=COUNT(*), b.enterprise_id=35}, 91=[COUNT(*), 35 AS enterprise_id]})
> Group(groups=[c], props={90=[COUNT(*)], 114=0.0, 80=[enterprise_id], 81=[COUNT(*)]})
> Null(groups=[c], props={90=[enterprise_id], 114=0.0})
> PROCESSOR PLAN:
> ProjectNode(1) output=[b."count", enterprise_id] [b."count", enterprise_id]
> ProjectNode(2) output=[b."count", enterprise_id] [COUNT(*), 35 AS enterprise_id]
> GroupingNode(3) output=[COUNT(*)] [enterprise_id]
> NullNode(4) output=[enterprise_id]
> Except the NullNode node contains enterprise_id as its target column vs an empty value.
--
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
14 years, 2 months
[JBoss JIRA] Moved: (TEIID-949) Criteria on constant column with aggregate function doesn't push criteria down correctly
by Steven Hawkins (JIRA)
[ https://jira.jboss.org/jira/browse/TEIID-949?page=com.atlassian.jira.plug... ]
Steven Hawkins moved JBEDSP-1150 to TEIID-949:
----------------------------------------------
Project: Teiid (was: JBoss Enterprise Data Services Platform)
Key: TEIID-949 (was: JBEDSP-1150)
Component/s: Query Engine
(was: Query)
Affects Version/s: 7.0
(was: 5.5.4)
> Criteria on constant column with aggregate function doesn't push criteria down correctly
> ----------------------------------------------------------------------------------------
>
> Key: TEIID-949
> URL: https://jira.jboss.org/jira/browse/TEIID-949
> Project: Teiid
> Issue Type: Bug
> Components: Query Engine
> Affects Versions: 7.0
> Environment: MM5.5.4
> Reporter: Larry O'Leary
> Assignee: Larry O'Leary
>
> When a column value is a constant and used along with an aggregate, criteria on the constant column is being ignored. Here is an example query:
> SELECT * FROM (
> SELECT b.count, enterprise_id FROM (
> SELECT COUNT(*), 35 AS enterprise_id FROM (
> SELECT "A Name" AS Name, 37 AS enterprise_id
> ) c
> ) b
> ) a WHERE enterprise_id = 1 OPTION DEBUG
> The expected result is an empty result set. Instead, the result set comes back as:
> COUNT, ENTERPRISE_ID
> 0, 35
> The resulting plan looks like:
> OPTIMIZATION COMPLETE:
> PLAN TREE:
> (type=Relational, command=SELECT * FROM (SELECT b."count", enterprise_id FROM (SELECT COUNT(*), 35 AS enterprise_id FROM (SELECT 'A Name' AS Name, 37 AS enterprise_id) AS c) AS b) AS a WHERE enterprise_id = 1 OPTION DEBUG, props={0=PlanHints})
> canonical plan:
> Project(groups=[b], props={90=[b."count", enterprise_id], 30=[b."count", enterprise_id], 114=0.0, 91=[A."COUNT", A.ENTERPRISE_ID]})
> Source(groups=[b], props={90=[b."count", enterprise_id], 64=SELECT COUNT(*), 35 AS enterprise_id FROM (SELECT 'A Name' AS Name, 37 AS enterprise_id) AS c, 114=0.0, 60={b."count"=COUNT(*), b.enterprise_id=35}})
> Project(groups=[], props={90=[b."count", enterprise_id], 30=[COUNT(*), 35 AS enterprise_id], 114=0.0, 60={b."count"=COUNT(*), b.enterprise_id=35}, 91=[COUNT(*), 35 AS enterprise_id]})
> Group(groups=[c], props={90=[COUNT(*)], 114=0.0, 81=[COUNT(*)]})
> Null(groups=[c], props={90=[], 114=0.0})
> PROCESSOR PLAN:
> ProjectNode(1) output=[b."count", enterprise_id] [b."count", enterprise_id]
> ProjectNode(2) output=[b."count", enterprise_id] [COUNT(*), 35 AS enterprise_id]
> GroupingNode(3) output=[COUNT(*)] null
> NullNode(4) output=[]
> If the query is changed as follows, the expected result is received:
> SELECT * FROM (
> SELECT b.count, enterprise_id FROM (
> SELECT COUNT(*), 35 AS enterprise_id FROM (
> SELECT "A Name" AS Name, 37 AS enterprise_id
> ) c GROUP BY enterprise_id
> ) b
> ) a WHERE enterprise_id = 1 OPTION DEBUG
> Which yields a very similar plan:
> PLAN TREE:
> (type=Relational, command=SELECT * FROM (SELECT b."count", enterprise_id FROM (SELECT COUNT(*), 35 AS enterprise_id FROM (SELECT 'A Name' AS Name, 37 AS enterprise_id) AS c GROUP BY enterprise_id) AS b) AS a WHERE enterprise_id = 1 OPTION DEBUG, props={0=PlanHints})
> canonical plan:
> Project(groups=[b], props={90=[b."count", enterprise_id], 30=[b."count", enterprise_id], 114=0.0, 91=[A."COUNT", A.ENTERPRISE_ID]})
> Source(groups=[b], props={90=[b."count", enterprise_id], 64=SELECT COUNT(*), 35 AS enterprise_id FROM (SELECT 'A Name' AS Name, 37 AS enterprise_id) AS c GROUP BY enterprise_id, 114=0.0, 60={b."count"=COUNT(*), b.enterprise_id=35}})
> Project(groups=[], props={90=[b."count", enterprise_id], 30=[COUNT(*), 35 AS enterprise_id], 114=0.0, 60={b."count"=COUNT(*), b.enterprise_id=35}, 91=[COUNT(*), 35 AS enterprise_id]})
> Group(groups=[c], props={90=[COUNT(*)], 114=0.0, 80=[enterprise_id], 81=[COUNT(*)]})
> Null(groups=[c], props={90=[enterprise_id], 114=0.0})
> PROCESSOR PLAN:
> ProjectNode(1) output=[b."count", enterprise_id] [b."count", enterprise_id]
> ProjectNode(2) output=[b."count", enterprise_id] [COUNT(*), 35 AS enterprise_id]
> GroupingNode(3) output=[COUNT(*)] [enterprise_id]
> NullNode(4) output=[enterprise_id]
> Except the NullNode node contains enterprise_id as its target column vs an empty value.
--
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
14 years, 2 months
[JBoss JIRA] Commented: (TEIID-502) Allow Multiple UDF Definition Models
by Ramesh Reddy (JIRA)
[ https://jira.jboss.org/jira/browse/TEIID-502?page=com.atlassian.jira.plug... ]
Ramesh Reddy commented on TEIID-502:
------------------------------------
By allowing the user to have a "FunctionDefinition.xml" per VDB this can be solved. However this removes support for the global "FunctionDefinitions.xmi". Also this aids to deploy the UDF module in single VDB artifact. User who are using the this UDF in global nature can get same features by adding this file to every VDB they are used in. Any supporting JAR file needs to be in the "lib" directory of the Container.
> Allow Multiple UDF Definition Models
> ------------------------------------
>
> Key: TEIID-502
> URL: https://jira.jboss.org/jira/browse/TEIID-502
> Project: Teiid
> Issue Type: Sub-task
> Components: Query Engine
> Reporter: Debbie Steigner
> Assignee: Ramesh Reddy
> Fix For: 7.0
>
>
> Customer feature request from Issue Tracker ticket# 228151:
> The current mechanism for UDF (user-defined functions) is limited to having one model (FunctionDefinitions.xmi) in which UDF are defined and related to their Java implementations. This results in a configuration management problem even on just one project. For multiple projects it becomes a nightmare, unless we abandon all hope of building a body of reusable UDFs. I would therefore suggest that designer and server need to support multiple UDF definition models, identified by the extensions already defined and used for FunctionDefinitions.xmi.
> Similar to JBEDSP-632
--
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
14 years, 3 months
[JBoss JIRA] Updated: (TEIID-502) Allow Multiple UDF Definition Models
by Ramesh Reddy (JIRA)
[ https://jira.jboss.org/jira/browse/TEIID-502?page=com.atlassian.jira.plug... ]
Ramesh Reddy updated TEIID-502:
-------------------------------
Parent: TEIID-833
Issue Type: Sub-task (was: Feature Request)
> Allow Multiple UDF Definition Models
> ------------------------------------
>
> Key: TEIID-502
> URL: https://jira.jboss.org/jira/browse/TEIID-502
> Project: Teiid
> Issue Type: Sub-task
> Components: Query Engine
> Reporter: Debbie Steigner
> Assignee: Ramesh Reddy
> Fix For: 7.0
>
>
> Customer feature request from Issue Tracker ticket# 228151:
> The current mechanism for UDF (user-defined functions) is limited to having one model (FunctionDefinitions.xmi) in which UDF are defined and related to their Java implementations. This results in a configuration management problem even on just one project. For multiple projects it becomes a nightmare, unless we abandon all hope of building a body of reusable UDFs. I would therefore suggest that designer and server need to support multiple UDF definition models, identified by the extensions already defined and used for FunctionDefinitions.xmi.
> Similar to JBEDSP-632
--
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
14 years, 3 months