[JBoss JIRA] (TEIID-3583) Need documentation on possible property settings to use
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-3583?page=com.atlassian.jira.plugin... ]
Steven Hawkins commented on TEIID-3583:
---------------------------------------
Yes the changes in the documentation commit are fine to pull back. In general the only things from master that aren't relevant are about the change to allow larger internal row counts, such as with temp tables.
> Need documentation on possible property settings to use
> -------------------------------------------------------
…
[View More]>
> Key: TEIID-3583
> URL: https://issues.jboss.org/browse/TEIID-3583
> Project: Teiid
> Issue Type: Enhancement
> Components: Documentation
> Reporter: Van Halbert
> Assignee: Steven Hawkins
> Fix For: 9.0
>
>
> In the Administration and Configuration Guide there is some indication on how to perform active heap throttling.
> "Memory Management Considerations " there is a reference to parameters like:
> max-processing-kb and the max-reserve-kb.
> Anyway there is no indication of the indicative values to associate to those parameters to obtain a certain result.
> It would be good to get some examples to understand the cause and effect of the changes ( max-reserve-kb and related settings ).
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
[View Less]
8 years, 7 months
[JBoss JIRA] (TEIID-4406) group by cast(... as date) results in NullPointException
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-4406?page=com.atlassian.jira.plugin... ]
Steven Hawkins resolved TEIID-4406.
-----------------------------------
Fix Version/s: 9.1
9.0.4
Resolution: Done
Added logic to account for leaving the dependent predicates above the grouping node.
> group by cast(... as date) results in NullPointException
> --------------------------------------------------------
>
> Key: TEIID-4406
> …
[View More] URL: https://issues.jboss.org/browse/TEIID-4406
> Project: Teiid
> Issue Type: Bug
> Components: Query Engine
> Affects Versions: 9.0.2
> Reporter: Bram Gadeyne
> Assignee: Steven Hawkins
> Fix For: 9.1, 9.0.4
>
> Attachments: plan_cast.txt, plan_nocast.txt
>
>
> example query:
> select oc.patientid, cast(oc.StartOfPeriod as date) as periodstart,
> max(case when variableid = 10001001 then oc.Value end) as sofa_resp,
> max(case when variableid = 10001002 then oc.Value end) as sofa_cardio,
> max(case when variableid = 10001003 then oc.Value end) as sofa_liver,
> max(case when variableid = 10001004 then oc.Value end) as sofa_coag,
> max(case when variableid = 10001005 then oc.Value end) as sofa_cns,
> max(case when variableid = 10001006 then oc.Value end) as sofa_renal,
> max(case when variableid = 30010000 then oc.Value end) as sofa_total
> from #tmp_cohort10 c
> join oldcos_scores oc on oc.PatientID = c.patientid
> group by oc.patientid, cast(oc.StartOfPeriod as date)
> stacktrace:
> 2016-08-23 11:46:25,263 ERROR [org.teiid.PROCESSOR] (Worker50_QueryProcessorQueue784) BCXKsyPCGz6r TEIID30019 Unexpected exception for request BCXKsyPCGz6r.148: java.lang.NullPointerException
> at org.teiid.dqp.internal.datamgr.LanguageBridgeFactory.translate(LanguageBridgeFactory.java:426)
> at org.teiid.dqp.internal.datamgr.LanguageBridgeFactory.translate(LanguageBridgeFactory.java:418)
> at org.teiid.dqp.internal.datamgr.LanguageBridgeFactory.translate(LanguageBridgeFactory.java:281)
> at org.teiid.dqp.internal.datamgr.LanguageBridgeFactory.translate(LanguageBridgeFactory.java:226)
> at org.teiid.dqp.internal.datamgr.LanguageBridgeFactory.translate(LanguageBridgeFactory.java:386)
> at org.teiid.dqp.internal.datamgr.LanguageBridgeFactory.translate(LanguageBridgeFactory.java:344)
> at org.teiid.dqp.internal.datamgr.LanguageBridgeFactory.translate(LanguageBridgeFactory.java:276)
> at org.teiid.dqp.internal.datamgr.LanguageBridgeFactory.translate(LanguageBridgeFactory.java:184)
> at org.teiid.dqp.internal.datamgr.ConnectorWorkItem.<init>(ConnectorWorkItem.java:175)
> at org.teiid.dqp.internal.datamgr.ConnectorManager.registerRequest(ConnectorManager.java:203)
> at org.teiid.dqp.internal.process.DataTierManagerImpl.registerRequest(DataTierManagerImpl.java:1011)
> at org.teiid.query.tempdata.TempTableDataManager.registerRequest(TempTableDataManager.java:179)
> at org.teiid.query.processor.relational.AccessNode.registerRequest(AccessNode.java:500)
> at org.teiid.query.processor.relational.AccessNode.openInternal(AccessNode.java:268)
> at org.teiid.query.processor.relational.AccessNode.open(AccessNode.java:171)
> at org.teiid.query.processor.relational.JoinStrategy.openRight(JoinStrategy.java:105)
> at org.teiid.query.processor.relational.JoinNode.nextBatchDirect(JoinNode.java:223)
> at org.teiid.query.processor.relational.RelationalNode.nextBatch(RelationalNode.java:282)
> at org.teiid.query.processor.BatchCollector$BatchProducerTupleSource.nextTuple(BatchCollector.java:94)
> at org.teiid.query.processor.relational.GroupingNode.groupSortPhase(GroupingNode.java:490)
> at org.teiid.query.processor.relational.GroupingNode.nextBatchDirect(GroupingNode.java:366)
> at org.teiid.query.processor.relational.RelationalNode.nextBatch(RelationalNode.java:282)
> at org.teiid.query.processor.relational.ProjectNode.nextBatchDirect(ProjectNode.java:150)
> at org.teiid.query.processor.relational.RelationalNode.nextBatch(RelationalNode.java:282)
> at org.teiid.query.processor.relational.RelationalPlan.nextBatch(RelationalPlan.java:145)
> at org.teiid.query.processor.QueryProcessor.nextBatchDirect(QueryProcessor.java:151)
> at org.teiid.query.processor.QueryProcessor.nextBatch(QueryProcessor.java:114)
> at org.teiid.query.processor.BatchCollector.collectTuples(BatchCollector.java:164)
> at org.teiid.query.processor.BatchCollector.collectTuples(BatchCollector.java:146)
> at org.teiid.dqp.internal.process.RequestWorkItem.processMore(RequestWorkItem.java:472)
> at org.teiid.dqp.internal.process.RequestWorkItem.process(RequestWorkItem.java:348)
> at org.teiid.dqp.internal.process.AbstractWorkItem.run(AbstractWorkItem.java:51)
> at org.teiid.dqp.internal.process.RequestWorkItem.run(RequestWorkItem.java:274)
> at org.teiid.dqp.internal.process.DQPWorkContext.runInContext(DQPWorkContext.java:276)
> at org.teiid.dqp.internal.process.ThreadReuseExecutor$RunnableWrapper.run(ThreadReuseExecutor.java:119)
> at org.teiid.dqp.internal.process.ThreadReuseExecutor$3.run(ThreadReuseExecutor.java:210)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
[View Less]
8 years, 7 months
[JBoss JIRA] (TEIID-4406) group by cast(... as date) results in NullPointException
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-4406?page=com.atlassian.jira.plugin... ]
Steven Hawkins updated TEIID-4406:
----------------------------------
Component/s: Query Engine
> group by cast(... as date) results in NullPointException
> --------------------------------------------------------
>
> Key: TEIID-4406
> URL: https://issues.jboss.org/browse/TEIID-4406
> Project: Teiid
> Issue Type: Bug
> …
[View More]Components: Query Engine
> Affects Versions: 9.0.2
> Reporter: Bram Gadeyne
> Assignee: Steven Hawkins
> Attachments: plan_cast.txt, plan_nocast.txt
>
>
> example query:
> select oc.patientid, cast(oc.StartOfPeriod as date) as periodstart,
> max(case when variableid = 10001001 then oc.Value end) as sofa_resp,
> max(case when variableid = 10001002 then oc.Value end) as sofa_cardio,
> max(case when variableid = 10001003 then oc.Value end) as sofa_liver,
> max(case when variableid = 10001004 then oc.Value end) as sofa_coag,
> max(case when variableid = 10001005 then oc.Value end) as sofa_cns,
> max(case when variableid = 10001006 then oc.Value end) as sofa_renal,
> max(case when variableid = 30010000 then oc.Value end) as sofa_total
> from #tmp_cohort10 c
> join oldcos_scores oc on oc.PatientID = c.patientid
> group by oc.patientid, cast(oc.StartOfPeriod as date)
> stacktrace:
> 2016-08-23 11:46:25,263 ERROR [org.teiid.PROCESSOR] (Worker50_QueryProcessorQueue784) BCXKsyPCGz6r TEIID30019 Unexpected exception for request BCXKsyPCGz6r.148: java.lang.NullPointerException
> at org.teiid.dqp.internal.datamgr.LanguageBridgeFactory.translate(LanguageBridgeFactory.java:426)
> at org.teiid.dqp.internal.datamgr.LanguageBridgeFactory.translate(LanguageBridgeFactory.java:418)
> at org.teiid.dqp.internal.datamgr.LanguageBridgeFactory.translate(LanguageBridgeFactory.java:281)
> at org.teiid.dqp.internal.datamgr.LanguageBridgeFactory.translate(LanguageBridgeFactory.java:226)
> at org.teiid.dqp.internal.datamgr.LanguageBridgeFactory.translate(LanguageBridgeFactory.java:386)
> at org.teiid.dqp.internal.datamgr.LanguageBridgeFactory.translate(LanguageBridgeFactory.java:344)
> at org.teiid.dqp.internal.datamgr.LanguageBridgeFactory.translate(LanguageBridgeFactory.java:276)
> at org.teiid.dqp.internal.datamgr.LanguageBridgeFactory.translate(LanguageBridgeFactory.java:184)
> at org.teiid.dqp.internal.datamgr.ConnectorWorkItem.<init>(ConnectorWorkItem.java:175)
> at org.teiid.dqp.internal.datamgr.ConnectorManager.registerRequest(ConnectorManager.java:203)
> at org.teiid.dqp.internal.process.DataTierManagerImpl.registerRequest(DataTierManagerImpl.java:1011)
> at org.teiid.query.tempdata.TempTableDataManager.registerRequest(TempTableDataManager.java:179)
> at org.teiid.query.processor.relational.AccessNode.registerRequest(AccessNode.java:500)
> at org.teiid.query.processor.relational.AccessNode.openInternal(AccessNode.java:268)
> at org.teiid.query.processor.relational.AccessNode.open(AccessNode.java:171)
> at org.teiid.query.processor.relational.JoinStrategy.openRight(JoinStrategy.java:105)
> at org.teiid.query.processor.relational.JoinNode.nextBatchDirect(JoinNode.java:223)
> at org.teiid.query.processor.relational.RelationalNode.nextBatch(RelationalNode.java:282)
> at org.teiid.query.processor.BatchCollector$BatchProducerTupleSource.nextTuple(BatchCollector.java:94)
> at org.teiid.query.processor.relational.GroupingNode.groupSortPhase(GroupingNode.java:490)
> at org.teiid.query.processor.relational.GroupingNode.nextBatchDirect(GroupingNode.java:366)
> at org.teiid.query.processor.relational.RelationalNode.nextBatch(RelationalNode.java:282)
> at org.teiid.query.processor.relational.ProjectNode.nextBatchDirect(ProjectNode.java:150)
> at org.teiid.query.processor.relational.RelationalNode.nextBatch(RelationalNode.java:282)
> at org.teiid.query.processor.relational.RelationalPlan.nextBatch(RelationalPlan.java:145)
> at org.teiid.query.processor.QueryProcessor.nextBatchDirect(QueryProcessor.java:151)
> at org.teiid.query.processor.QueryProcessor.nextBatch(QueryProcessor.java:114)
> at org.teiid.query.processor.BatchCollector.collectTuples(BatchCollector.java:164)
> at org.teiid.query.processor.BatchCollector.collectTuples(BatchCollector.java:146)
> at org.teiid.dqp.internal.process.RequestWorkItem.processMore(RequestWorkItem.java:472)
> at org.teiid.dqp.internal.process.RequestWorkItem.process(RequestWorkItem.java:348)
> at org.teiid.dqp.internal.process.AbstractWorkItem.run(AbstractWorkItem.java:51)
> at org.teiid.dqp.internal.process.RequestWorkItem.run(RequestWorkItem.java:274)
> at org.teiid.dqp.internal.process.DQPWorkContext.runInContext(DQPWorkContext.java:276)
> at org.teiid.dqp.internal.process.ThreadReuseExecutor$RunnableWrapper.run(ThreadReuseExecutor.java:119)
> at org.teiid.dqp.internal.process.ThreadReuseExecutor$3.run(ThreadReuseExecutor.java:210)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
[View Less]
8 years, 7 months
[JBoss JIRA] (TEIID-4235) dynamic sql recursion check not valid after caught exception
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/TEIID-4235?page=com.atlassian.jira.plugin... ]
RH Bugzilla Integration commented on TEIID-4235:
------------------------------------------------
Debi Rieden <drieden(a)redhat.com> changed the Status of [bug 1341654|https://bugzilla.redhat.com/show_bug.cgi?id=1341654] from VERIFIED to CLOSED
> dynamic sql recursion check not valid after caught exception
> ------------------------------------------------------------
>
> Key: …
[View More]TEIID-4235
> URL: https://issues.jboss.org/browse/TEIID-4235
> Project: Teiid
> Issue Type: Bug
> Components: Query Engine
> Affects Versions: 8.7
> Reporter: Steven Hawkins
> Assignee: Steven Hawkins
> Fix For: 9.0, 8.12.5, 8.13.5
>
>
> With a procedure like:
> begin
> execute immediate
> exception e
> ...
> execute immediate ...
> An exception on the second execute immediate will be seen like:
> org.teiid.api.exception.query.QueryProcessingException: TEIID30168 Couldn't execute the dynamic SQL command "EXECUTE IMMEDIATE ..." due to: TEIID30347 There is a recursive invocation of group 'proc'. Please correct the SQL.
> Even when the dynamic sql does not re-invoke the proc. The issue is that when catching the initial exception thrown doesn't clear the entry from the recursion stack.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
[View Less]
8 years, 7 months
[JBoss JIRA] (TEIID-4021) MSSQL Pagination
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-4021?page=com.atlassian.jira.plugin... ]
Steven Hawkins commented on TEIID-4021:
---------------------------------------
That is expected behavior. It is assumed that a given translator is talking to a single database type/version. In a heterogeneous case you will need to manually set the database version property on the executionfactory to the lowest version.
> MSSQL Pagination
> ----------------
>
> Key: TEIID-4021
> …
[View More] URL: https://issues.jboss.org/browse/TEIID-4021
> Project: Teiid
> Issue Type: Enhancement
> Components: JDBC Connector
> Reporter: Mark Tawk
> Assignee: Steven Hawkins
> Fix For: 9.1
>
>
> I'm using Teiid 8.11.3 with mssql translator.
> I have a huge table over sql server 2008 on which i'm applying pagination.
> I noticed slowliness in the query execution over this table at each time I increase the pagination.
> I monitored the JDBC queries execute by teiid and found out that it is using top n according to the limit used into the query.
> For example:
> in teiid : Select * from mytable LIMIT 90 , 10
> is translated in JDBC: select top 100 from mytable
> Since my table contains millions of records, when fetching the last page, the executed jdbc query is retrieving the whole table top n, to return in result the last 10 records. And the execution is taking too much time.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
[View Less]
8 years, 7 months
[JBoss JIRA] (TEIID-4021) MSSQL Pagination
by Mark Tawk (JIRA)
[ https://issues.jboss.org/browse/TEIID-4021?page=com.atlassian.jira.plugin... ]
Mark Tawk edited comment on TEIID-4021 at 8/29/16 9:52 AM:
-----------------------------------------------------------
I'm using teiid embedded, how can I get the source / translator configuration of the vdb?
Otherwise, i have debugged into SQLServerExecutionFactory.java; in fact, when executing the first MSSQL query it is assigning MSSQL version in initCapabilities method. And it is keeping the same value for "…
[View More]version" property for the next executed mssql queries without reassigning it from the used connection.
In my case, the property "version" in SQLServerExecutionFactory class is assigned to "11.0.2100" for mssql 2012, and when running a query on mssql 2008, "version" property is not reassigned and it keeps using the initial value "11.0.2100".
was (Author: mtawk):
I'm using teiid embedded, how can I get the source / translator configuration of the vdb?
Otherwise, i have debugged into SQLServerExecutionFactory.java; in fact, when executing the first MSSQL query it is assigning MSSQL version in initCapabilities method. And it is keeping the same value version property for the next executed mssql queries without reassigning it from the used connection.
In my case, the property "version" in SQLServerExecutionFactory class is assigned to "11.0.2100" for mssql 2012, and when running a query on mssql 2008, "version" property is not reassigned and it keeps using the initial value "11.0.2100".
> MSSQL Pagination
> ----------------
>
> Key: TEIID-4021
> URL: https://issues.jboss.org/browse/TEIID-4021
> Project: Teiid
> Issue Type: Enhancement
> Components: JDBC Connector
> Reporter: Mark Tawk
> Assignee: Steven Hawkins
> Fix For: 9.1
>
>
> I'm using Teiid 8.11.3 with mssql translator.
> I have a huge table over sql server 2008 on which i'm applying pagination.
> I noticed slowliness in the query execution over this table at each time I increase the pagination.
> I monitored the JDBC queries execute by teiid and found out that it is using top n according to the limit used into the query.
> For example:
> in teiid : Select * from mytable LIMIT 90 , 10
> is translated in JDBC: select top 100 from mytable
> Since my table contains millions of records, when fetching the last page, the executed jdbc query is retrieving the whole table top n, to return in result the last 10 records. And the execution is taking too much time.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
[View Less]
8 years, 7 months
[JBoss JIRA] (TEIID-4021) MSSQL Pagination
by Mark Tawk (JIRA)
[ https://issues.jboss.org/browse/TEIID-4021?page=com.atlassian.jira.plugin... ]
Mark Tawk commented on TEIID-4021:
----------------------------------
I'm using teiid embedded, how can I get the source / translator configuration of the vdb?
Otherwise, i have debugged into SQLServerExecutionFactory.java; in fact, when executing the first MSSQL query it is assigning MSSQL version in initCapabilities method. And it is keeping the same value version property for the next executed mssql queries …
[View More]without reassigning it from the used connection.
In my case, the property "version" in SQLServerExecutionFactory class is assigned to "11.0.2100" for mssql 2012, and when running a query on mssql 2008, "version" property is not reassigned and it keeps using the initial value "11.0.2100".
> MSSQL Pagination
> ----------------
>
> Key: TEIID-4021
> URL: https://issues.jboss.org/browse/TEIID-4021
> Project: Teiid
> Issue Type: Enhancement
> Components: JDBC Connector
> Reporter: Mark Tawk
> Assignee: Steven Hawkins
> Fix For: 9.1
>
>
> I'm using Teiid 8.11.3 with mssql translator.
> I have a huge table over sql server 2008 on which i'm applying pagination.
> I noticed slowliness in the query execution over this table at each time I increase the pagination.
> I monitored the JDBC queries execute by teiid and found out that it is using top n according to the limit used into the query.
> For example:
> in teiid : Select * from mytable LIMIT 90 , 10
> is translated in JDBC: select top 100 from mytable
> Since my table contains millions of records, when fetching the last page, the executed jdbc query is retrieving the whole table top n, to return in result the last 10 records. And the execution is taking too much time.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
[View Less]
8 years, 7 months
[JBoss JIRA] (TEIID-4021) MSSQL Pagination
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-4021?page=com.atlassian.jira.plugin... ]
Steven Hawkins commented on TEIID-4021:
---------------------------------------
What does the source / translator configuration look like for your vdb?
> MSSQL Pagination
> ----------------
>
> Key: TEIID-4021
> URL: https://issues.jboss.org/browse/TEIID-4021
> Project: Teiid
> Issue Type: Enhancement
> Components: JDBC …
[View More]Connector
> Reporter: Mark Tawk
> Assignee: Steven Hawkins
> Fix For: 9.1
>
>
> I'm using Teiid 8.11.3 with mssql translator.
> I have a huge table over sql server 2008 on which i'm applying pagination.
> I noticed slowliness in the query execution over this table at each time I increase the pagination.
> I monitored the JDBC queries execute by teiid and found out that it is using top n according to the limit used into the query.
> For example:
> in teiid : Select * from mytable LIMIT 90 , 10
> is translated in JDBC: select top 100 from mytable
> Since my table contains millions of records, when fetching the last page, the executed jdbc query is retrieving the whole table top n, to return in result the last 10 records. And the execution is taking too much time.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
[View Less]
8 years, 7 months