[
https://issues.jboss.org/browse/TEIID-4113?page=com.atlassian.jira.plugin...
]
Steven Hawkins commented on TEIID-4113:
---------------------------------------
I can't get a plan WITH parsetimestamp as the statement just
errors.
The plan should be there even if there is an error. You would just catch the error and
still call show plan.
Just to confirm, what release are you seeing this issue on?
If I run the query shown with slightly modified metadata from your updated test, I still
see an appropriate query. Is it possible you are not on 8.13.3?
Impala translator - Incorrect aggregate replacement in query
------------------------------------------------------------
Key: TEIID-4113
URL:
https://issues.jboss.org/browse/TEIID-4113
Project: Teiid
Issue Type: Bug
Components: JDBC Connector
Affects Versions: 8.13.3
Environment: Ubuntu Trusty
Reporter: Don Krapohl
Assignee: Steven Hawkins
Labels: Impala_Translator
Attachments: parsetimestamp-plan.txt
When PARSETIMESTAMP is included in a query aggregates in other columns may not be written
correctly. Example is as below, sum(first_metric) is rewritten to anon_grp0.agg0 in the
query sent to Impala.
Given the schema:
//source
SourceTable
the_attribute string(255),
first_metric long,
second_metric bigdecimal
another_attribute String(255)
//view
VirtualTable
the_attribute string(255),
first_metric long,
second_metric bigdecimal
another_attribute String(255)
// Teiid query
SELECT the_attribute,
cast(
sum(
first_metric
)
/
count(
distinct case when second_metric >= 0 then second_metric end
) as double
) as some_alias,
PARSETIMESTAMP(another_attribute, 'yyyy-MM-dd') as somedate
FROM VirtualTable
WHERE a_filter_val=111
GROUP BY the_attribute, another_attribute
//Query sent to impala
SELECT g_0.the_attribute AS c_0,
cast(
(
anon_grp0.agg0
/
cast(
anon_grp0.agg1 AS bigint
)
) AS double
) AS c_1,
g_0.another_attribute AS c_2
FROM VirtualTable
WHERE a_filter_val=111
GROUP BY g_0.the_attribute, g_0.another_attribute
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)