[JBoss JIRA] (TEIID-2565) Problem with DDL returned via admin api - column has erroneous datatype
by Mark Drilling (JIRA)
Mark Drilling created TEIID-2565:
------------------------------------
Summary: Problem with DDL returned via admin api - column has erroneous datatype
Key: TEIID-2565
URL: https://issues.jboss.org/browse/TEIID-2565
Project: Teiid
Issue Type: Bug
Components: AdminApi
Affects Versions: 8.4
Reporter: Mark Drilling
Assignee: Ramesh Reddy
Deployed a greenplum datasource, then deployed a dynamic vdb and did a getSchema via the admin api. One of the tables in the ddl contains a column as shown in the following ddl snippet:
CREATE FOREIGN TABLE "gp_toolkit.gp_log_command_timings" (
logduration object(49) OPTIONS (NAMEINSOURCE '"logduration"', NATIVE_TYPE 'interval')
) OPTIONS (NAMEINSOURCE '"gp_toolkit"."gp_log_command_timings"', UPDATABLE TRUE);
The logduration type of object erroneously has a length.
--
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, 5 months
[JBoss JIRA] (TEIID-2564) Correlated subqueries throws TEIID30328
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-2564?page=com.atlassian.jira.plugin... ]
Steven Hawkins updated TEIID-2564:
----------------------------------
Summary: Correlated subqueries throws TEIID30328 (was: Netezza queries returning "TEIID30328 Unable to evaluate A.IntKey: No value was available")
Fix Version/s: 8.4.1
8.5
Description:
Non-pushed correlated subqueries that use a correlation variable that is a grouping column where the subquery is turned into a semi join (either through the MJ hint or costing) will fail to find the correlation values.
For example the following against Netezza (which does not support correlated subqueries):
SELECT A.INTKEY, A.STRINGNUM FROM BQT1.SMALLA AS A WHERE CONVERT(LONGNUM,
STRING) = 8 GROUP BY A.INTKEY, A.STRINGNUM HAVING A.STRINGNUM = (SELECT
MAX(B.STRINGNUM) FROM BQT1.SMALLA AS B WHERE A.INTKEY = B.INTKEY
throws "TEIID30328 Unable to evaluate A.IntKey: No value was available"
If the subplan is not converted to a join or the correlated column is not a grouping expression, then there is no issue.
was:
Netezza queries returning "TEIID30328 Unable to evaluate A.IntKey:
No value was available". Queries involved all use HAVING.
The log file is attached.
A couple example queries are:
SELECT A.INTKEY, A.STRINGNUM FROM BQT1.SMALLA AS A WHERE CONVERT(LONGNUM,
STRING) = 8 GROUP BY A.INTKEY, A.STRINGNUM HAVING A.STRINGNUM = (SELECT
MAX(B.STRINGNUM) FROM BQT1.SMALLA AS B WHERE A.INTKEY = B.INTKEY
SELECT A.INTKEY, A.FLOATNUM FROM BQT1.SMALLA AS A WHERE NOT (A.INTNUM IS
NULL) GROUP BY A.INTKEY, A.FLOATNUM HAVING A.FLOATNUM = (SELECT
MIN(B.FLOATNUM) FROM BQT1.SMALLA AS B WHERE A.INTKEY = B.INTKEY
Analysis from engineering:
The issue is happening when a the subquery is converted to a join (this is happening under to covers based upon the costing of the subquery plan) and the correlated column is a grouping expression.
If the subplan is not converted to a join or the correlated column is not a grouping expression, then there is no issue.
> Correlated subqueries throws TEIID30328
> ---------------------------------------
>
> Key: TEIID-2564
> URL: https://issues.jboss.org/browse/TEIID-2564
> Project: Teiid
> Issue Type: Bug
> Components: Query Engine
> Affects Versions: 8.4
> Reporter: Warren Gibson
> Assignee: Steven Hawkins
> Fix For: 8.4.1, 8.5
>
> Attachments: server.log
>
>
> Non-pushed correlated subqueries that use a correlation variable that is a grouping column where the subquery is turned into a semi join (either through the MJ hint or costing) will fail to find the correlation values.
> For example the following against Netezza (which does not support correlated subqueries):
> SELECT A.INTKEY, A.STRINGNUM FROM BQT1.SMALLA AS A WHERE CONVERT(LONGNUM,
> STRING) = 8 GROUP BY A.INTKEY, A.STRINGNUM HAVING A.STRINGNUM = (SELECT
> MAX(B.STRINGNUM) FROM BQT1.SMALLA AS B WHERE A.INTKEY = B.INTKEY
> throws "TEIID30328 Unable to evaluate A.IntKey: No value was available"
> If the subplan is not converted to a join or the correlated column is not a grouping expression, then there is no issue.
--
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, 5 months
[JBoss JIRA] (TEIID-2564) Netezza queries returning "TEIID30328 Unable to evaluate A.IntKey: No value was available"
by Warren Gibson (JIRA)
[ https://issues.jboss.org/browse/TEIID-2564?page=com.atlassian.jira.plugin... ]
Warren Gibson updated TEIID-2564:
---------------------------------
Attachment: server.log
> Netezza queries returning "TEIID30328 Unable to evaluate A.IntKey: No value was available"
> ------------------------------------------------------------------------------------------
>
> Key: TEIID-2564
> URL: https://issues.jboss.org/browse/TEIID-2564
> Project: Teiid
> Issue Type: Bug
> Components: Query Engine
> Affects Versions: 8.4
> Reporter: Warren Gibson
> Assignee: Steven Hawkins
> Attachments: server.log
>
>
> Netezza queries returning "TEIID30328 Unable to evaluate A.IntKey:
> No value was available". Queries involved all use HAVING.
> The log file is attached.
> A couple example queries are:
> SELECT A.INTKEY, A.STRINGNUM FROM BQT1.SMALLA AS A WHERE CONVERT(LONGNUM,
> STRING) = 8 GROUP BY A.INTKEY, A.STRINGNUM HAVING A.STRINGNUM = (SELECT
> MAX(B.STRINGNUM) FROM BQT1.SMALLA AS B WHERE A.INTKEY = B.INTKEY
> SELECT A.INTKEY, A.FLOATNUM FROM BQT1.SMALLA AS A WHERE NOT (A.INTNUM IS
> NULL) GROUP BY A.INTKEY, A.FLOATNUM HAVING A.FLOATNUM = (SELECT
> MIN(B.FLOATNUM) FROM BQT1.SMALLA AS B WHERE A.INTKEY = B.INTKEY
> Analysis from engineering:
> The issue is happening when a the subquery is converted to a join (this is happening under to covers based upon the costing of the subquery plan) and the correlated column is a grouping expression.
> If the subplan is not converted to a join or the correlated column is not a grouping expression, then there is no issue.
--
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, 5 months
[JBoss JIRA] (TEIID-2564) Netezza queries returning "TEIID30328 Unable to evaluate A.IntKey: No value was available"
by Warren Gibson (JIRA)
Warren Gibson created TEIID-2564:
------------------------------------
Summary: Netezza queries returning "TEIID30328 Unable to evaluate A.IntKey: No value was available"
Key: TEIID-2564
URL: https://issues.jboss.org/browse/TEIID-2564
Project: Teiid
Issue Type: Bug
Components: Query Engine
Affects Versions: 8.4
Reporter: Warren Gibson
Assignee: Steven Hawkins
Netezza queries returning "TEIID30328 Unable to evaluate A.IntKey:
No value was available". Queries involved all use HAVING.
The log file is attached.
A couple example queries are:
SELECT A.INTKEY, A.STRINGNUM FROM BQT1.SMALLA AS A WHERE CONVERT(LONGNUM,
STRING) = 8 GROUP BY A.INTKEY, A.STRINGNUM HAVING A.STRINGNUM = (SELECT
MAX(B.STRINGNUM) FROM BQT1.SMALLA AS B WHERE A.INTKEY = B.INTKEY
SELECT A.INTKEY, A.FLOATNUM FROM BQT1.SMALLA AS A WHERE NOT (A.INTNUM IS
NULL) GROUP BY A.INTKEY, A.FLOATNUM HAVING A.FLOATNUM = (SELECT
MIN(B.FLOATNUM) FROM BQT1.SMALLA AS B WHERE A.INTKEY = B.INTKEY
Analysis from engineering:
The issue is happening when a the subquery is converted to a join (this is happening under to covers based upon the costing of the subquery plan) and the correlated column is a grouping expression.
If the subplan is not converted to a join or the correlated column is not a grouping expression, then there is no issue.
--
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, 5 months
[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... ]
Steven Hawkins updated TEIID-2555:
----------------------------------
Description:
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).
was:
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.
The engine changes will be somewhat of a divergence from traditional planning in that we are effectively creating sub-plans from a single plan. The initial engine changes should be ready for an 8.5 Alpha1 release tomorrow.
This will be driven off the makedep hint expansion in TEIID-2559, using a JOIN or a FULL JOIN option to indicate that the entire join should be pushed down. The decision will not be able to be backed out of. It will be left for later releases for the engine to make the decision on its own to perform the full join pushdown.
> 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).
--
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, 5 months