[JBoss JIRA] (TEIID-5372) Enhance docker support
by Rafal Korytkowski (JIRA)
[ https://issues.jboss.org/browse/TEIID-5372?page=com.atlassian.jira.plugin... ]
Rafal Korytkowski commented on TEIID-5372:
------------------------------------------
Fair enough. It may be confusing to find both https://hub.docker.com/r/jboss/teiid/ and https://hub.docker.com/r/teiid/teiid/ so I'd go with Option 2.
> Enhance docker support
> ----------------------
>
> Key: TEIID-5372
> URL: https://issues.jboss.org/browse/TEIID-5372
> Project: Teiid
> Issue Type: Enhancement
> Reporter: Rafal Korytkowski
> Assignee: Rafal Korytkowski
> Priority: Optional
>
> Currently there's limited support for docker in Teiid, which can be enabled by adding -Ddocker=true to the build command. The generated image is based on CentOS and running standalone on the Wildfly server. Latest builds are pushed to https://hub.docker.com/r/jboss/teiid/, but versions are not tagged automatically with releases. Development with Docker is not supported.
> Proposed changes:
> 1. Produce docker image based on Alpine, which is better suited for microservices, in addition to CentOS.
> 2. Automatically tag versions in Docker when doing releases.
> 3. Support development by providing a docker-compose file with the possibility to start server in a debug mode and enabled auto-redeployment of code changes.
> 4. Optionally provide a Docker image for building code using maven in Docker. Having Docker as the only prerequisite is convenient for CI environments and makes the build environment agnostic.
> [~shawkins], [~rareddy], thoughts?
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 5 months
[JBoss JIRA] (TEIID-5406) Allow usage of long datatype as the increment parameter in TimestampAdd function
by dalex dalex (JIRA)
[ https://issues.jboss.org/browse/TEIID-5406?page=com.atlassian.jira.plugin... ]
dalex dalex updated TEIID-5406:
-------------------------------
Description:
Currently the TIMESTAMPADD(interval, count, timestamp) expects the count parameter to be integer. This is inconsistent with the return value of the TIMSTAMPDIFF function that is long. Thus we cannot take the fraction of the count returned by TIMSTAMPDIFF and submit it to TIMESTAMPADD. Since the SQL_TSI_FRAC_SECOND difference is too large for most human values (and it's the only way to retrieve millis, even though millions of millis), we need a way to submit this data to TIMSTAMPADD.
1. There is an inconsistency when adding 1 billion fractions of a second. Please execute the script below, one adds one billion minus one, the next one exactly 1bln fractions which results in two values, one of which is 1 fraction larger than expected:
{code:sql}
Select TimestampAdd(SQL_TSI_FRAC_SECOND, 999999999, Cast(CurDate() as timestamp))
Union All
Select TimestampAdd(SQL_TSI_FRAC_SECOND, 999999999 + 1, Cast(CurDate() as timestamp));;
{code}
2. Another example:
{code:sql}
Begin
Declare timestamp initialDate = CurDate();
Declare long diff = TimestampDiff(SQL_TSI_FRAC_SECOND, initialDate, TimestampAdd(SQL_TSI_DAY, 1, initialDate));
Declare timestamp back = TimestampAdd(SQL_TSI_FRAC_SECOND, diff, initialDate);
select initialDate, back;
End ;;
{code}
which leads to the following error message:
{code:noformat}
2018-07-03 10:10:33,942 WARN [org.teiid.PROCESSOR] (Worker7_QueryProcessorQueue47) 1RBg/ooz5vx7 TEIID30020 Processing exception for request 1RBg/ooz5vx7.27 'TEIID30070 The function
'TimestampAdd(SQL_TSI_FRAC_SECOND, VARIABLES.diff, VARIABLES.initialDate)' is a valid function form, but the arguments do not match a known type signature and cannot be converted usi
ng implicit type conversions.'. Originally QueryResolverException ResolverVisitor.java:757.: org.teiid.api.exception.query.QueryResolverException: TEIID30070 The function 'TimestampA
dd(SQL_TSI_FRAC_SECOND, VARIABLES.diff, VARIABLES.initialDate)' is a valid function form, but the arguments do not match a known type signature and cannot be converted using implicit
type conversions.
at org.teiid.query.resolver.util.ResolverVisitor.resolveFunction(ResolverVisitor.java:757)
at org.teiid.query.resolver.util.ResolverVisitor.visit(ResolverVisitor.java:392)
at org.teiid.query.sql.symbol.Function.acceptVisitor(Function.java:169)
at org.teiid.query.sql.navigator.AbstractNavigator.visitVisitor(AbstractNavigator.java:50)
at org.teiid.query.sql.navigator.PreOrPostOrderNavigator.postVisitVisitor(PreOrPostOrderNavigator.java:57)
at org.teiid.query.sql.navigator.PreOrPostOrderNavigator.visit(PreOrPostOrderNavigator.java:194)
at org.teiid.query.sql.symbol.Function.acceptVisitor(Function.java:169)
at org.teiid.query.resolver.util.ResolverVisitor.resolveLanguageObject(ResolverVisitor.java:1456)
at org.teiid.query.resolver.command.UpdateProcedureResolver.resolveStatement(UpdateProcedureResolver.java:234)
at org.teiid.query.resolver.command.UpdateProcedureResolver.resolveBlock(UpdateProcedureResolver.java:127)
at org.teiid.query.resolver.command.UpdateProcedureResolver.resolveCommand(UpdateProcedureResolver.java:110)
at org.teiid.query.resolver.QueryResolver.resolveCommand(QueryResolver.java:282)
at org.teiid.query.resolver.QueryResolver.resolveCommand(QueryResolver.java:128)
at org.teiid.dqp.internal.process.Request.resolveCommand(Request.java:282)
at org.teiid.dqp.internal.process.Request.generatePlan(Request.java:418)
at org.teiid.dqp.internal.process.Request.processRequest(Request.java:486)
at org.teiid.dqp.internal.process.RequestWorkItem.processNew(RequestWorkItem.java:660)
at org.teiid.dqp.internal.process.RequestWorkItem.process(RequestWorkItem.java:339)
at org.teiid.dqp.internal.process.AbstractWorkItem.run(AbstractWorkItem.java:47)
at org.teiid.dqp.internal.process.RequestWorkItem.run(RequestWorkItem.java:276)
at org.teiid.dqp.internal.process.DQPWorkContext.runInContext(DQPWorkContext.java:277)
at org.teiid.dqp.internal.process.ThreadReuseExecutor$RunnableWrapper.run(ThreadReuseExecutor.java:115)
at org.teiid.dqp.internal.process.ThreadReuseExecutor$3.run(ThreadReuseExecutor.java:206)
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)
{code}
was:
Currently the TIMESTAMPADD(interval, count, timestamp) expects the count parameter to be integer. This is inconsistent with the return value of the TIMSTAMPDIFF function that is long. Thus we cannot take the fraction of the count returned by TIMSTAMPDIFF and submit it to TIMESTAMPADD. Since the SQL_TSI_FRAC_SECOND difference is too large for most human values (and it's the only way to retrieve millis, even though millions of millis), we need a way to submit this data to TIMSTAMPADD.
1. There is an inconsistency when adding 1 billion fractions of a second. Please execute the script below, one adds one billion minus one, the next one exactly 1bln fractions which results in two values, one of which is 1 fraction larger than expected:
{code:sql}
Select TimestampAdd(SQL_TSI_FRAC_SECOND, 999999999, Cast(CurDate() as timestamp))
Union All
Select TimestampAdd(SQL_TSI_FRAC_SECOND, 999999999 + 1, Cast(CurDate() as timestamp));;
{code}
2. Another example:
{code:sql}
Begin
Declare timestamp initialDate = CurDate();
Declare long diff = TimestampDiff(SQL_TSI_FRAC_SECOND, initialDate, TimestampAdd(SQL_TSI_DAY, 1, initialDate));
Declare timestamp back = TimestampAdd(SQL_TSI_FRAC_SECOND, diff, initialDate);
select initialDate, back;
End ;;
{code}
which leads to following error message:
{code:noformat}
2018-07-03 10:10:33,942 WARN [org.teiid.PROCESSOR] (Worker7_QueryProcessorQueue47) 1RBg/ooz5vx7 TEIID30020 Processing exception for request 1RBg/ooz5vx7.27 'TEIID30070 The function
'TimestampAdd(SQL_TSI_FRAC_SECOND, VARIABLES.diff, VARIABLES.initialDate)' is a valid function form, but the arguments do not match a known type signature and cannot be converted usi
ng implicit type conversions.'. Originally QueryResolverException ResolverVisitor.java:757.: org.teiid.api.exception.query.QueryResolverException: TEIID30070 The function 'TimestampA
dd(SQL_TSI_FRAC_SECOND, VARIABLES.diff, VARIABLES.initialDate)' is a valid function form, but the arguments do not match a known type signature and cannot be converted using implicit
type conversions.
at org.teiid.query.resolver.util.ResolverVisitor.resolveFunction(ResolverVisitor.java:757)
at org.teiid.query.resolver.util.ResolverVisitor.visit(ResolverVisitor.java:392)
at org.teiid.query.sql.symbol.Function.acceptVisitor(Function.java:169)
at org.teiid.query.sql.navigator.AbstractNavigator.visitVisitor(AbstractNavigator.java:50)
at org.teiid.query.sql.navigator.PreOrPostOrderNavigator.postVisitVisitor(PreOrPostOrderNavigator.java:57)
at org.teiid.query.sql.navigator.PreOrPostOrderNavigator.visit(PreOrPostOrderNavigator.java:194)
at org.teiid.query.sql.symbol.Function.acceptVisitor(Function.java:169)
at org.teiid.query.resolver.util.ResolverVisitor.resolveLanguageObject(ResolverVisitor.java:1456)
at org.teiid.query.resolver.command.UpdateProcedureResolver.resolveStatement(UpdateProcedureResolver.java:234)
at org.teiid.query.resolver.command.UpdateProcedureResolver.resolveBlock(UpdateProcedureResolver.java:127)
at org.teiid.query.resolver.command.UpdateProcedureResolver.resolveCommand(UpdateProcedureResolver.java:110)
at org.teiid.query.resolver.QueryResolver.resolveCommand(QueryResolver.java:282)
at org.teiid.query.resolver.QueryResolver.resolveCommand(QueryResolver.java:128)
at org.teiid.dqp.internal.process.Request.resolveCommand(Request.java:282)
at org.teiid.dqp.internal.process.Request.generatePlan(Request.java:418)
at org.teiid.dqp.internal.process.Request.processRequest(Request.java:486)
at org.teiid.dqp.internal.process.RequestWorkItem.processNew(RequestWorkItem.java:660)
at org.teiid.dqp.internal.process.RequestWorkItem.process(RequestWorkItem.java:339)
at org.teiid.dqp.internal.process.AbstractWorkItem.run(AbstractWorkItem.java:47)
at org.teiid.dqp.internal.process.RequestWorkItem.run(RequestWorkItem.java:276)
at org.teiid.dqp.internal.process.DQPWorkContext.runInContext(DQPWorkContext.java:277)
at org.teiid.dqp.internal.process.ThreadReuseExecutor$RunnableWrapper.run(ThreadReuseExecutor.java:115)
at org.teiid.dqp.internal.process.ThreadReuseExecutor$3.run(ThreadReuseExecutor.java:206)
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)
{code}
> Allow usage of long datatype as the increment parameter in TimestampAdd function
> --------------------------------------------------------------------------------
>
> Key: TEIID-5406
> URL: https://issues.jboss.org/browse/TEIID-5406
> Project: Teiid
> Issue Type: Enhancement
> Components: Query Engine
> Affects Versions: 10.2
> Environment: teiid-10.2.0 on WildFly Full 11.0.0.Final (WildFly Core 3.0.8.Final)
> Reporter: dalex dalex
> Assignee: Steven Hawkins
>
> Currently the TIMESTAMPADD(interval, count, timestamp) expects the count parameter to be integer. This is inconsistent with the return value of the TIMSTAMPDIFF function that is long. Thus we cannot take the fraction of the count returned by TIMSTAMPDIFF and submit it to TIMESTAMPADD. Since the SQL_TSI_FRAC_SECOND difference is too large for most human values (and it's the only way to retrieve millis, even though millions of millis), we need a way to submit this data to TIMSTAMPADD.
> 1. There is an inconsistency when adding 1 billion fractions of a second. Please execute the script below, one adds one billion minus one, the next one exactly 1bln fractions which results in two values, one of which is 1 fraction larger than expected:
> {code:sql}
> Select TimestampAdd(SQL_TSI_FRAC_SECOND, 999999999, Cast(CurDate() as timestamp))
> Union All
> Select TimestampAdd(SQL_TSI_FRAC_SECOND, 999999999 + 1, Cast(CurDate() as timestamp));;
> {code}
> 2. Another example:
> {code:sql}
> Begin
> Declare timestamp initialDate = CurDate();
> Declare long diff = TimestampDiff(SQL_TSI_FRAC_SECOND, initialDate, TimestampAdd(SQL_TSI_DAY, 1, initialDate));
> Declare timestamp back = TimestampAdd(SQL_TSI_FRAC_SECOND, diff, initialDate);
> select initialDate, back;
> End ;;
> {code}
> which leads to the following error message:
> {code:noformat}
> 2018-07-03 10:10:33,942 WARN [org.teiid.PROCESSOR] (Worker7_QueryProcessorQueue47) 1RBg/ooz5vx7 TEIID30020 Processing exception for request 1RBg/ooz5vx7.27 'TEIID30070 The function
> 'TimestampAdd(SQL_TSI_FRAC_SECOND, VARIABLES.diff, VARIABLES.initialDate)' is a valid function form, but the arguments do not match a known type signature and cannot be converted usi
> ng implicit type conversions.'. Originally QueryResolverException ResolverVisitor.java:757.: org.teiid.api.exception.query.QueryResolverException: TEIID30070 The function 'TimestampA
> dd(SQL_TSI_FRAC_SECOND, VARIABLES.diff, VARIABLES.initialDate)' is a valid function form, but the arguments do not match a known type signature and cannot be converted using implicit
> type conversions.
> at org.teiid.query.resolver.util.ResolverVisitor.resolveFunction(ResolverVisitor.java:757)
> at org.teiid.query.resolver.util.ResolverVisitor.visit(ResolverVisitor.java:392)
> at org.teiid.query.sql.symbol.Function.acceptVisitor(Function.java:169)
> at org.teiid.query.sql.navigator.AbstractNavigator.visitVisitor(AbstractNavigator.java:50)
> at org.teiid.query.sql.navigator.PreOrPostOrderNavigator.postVisitVisitor(PreOrPostOrderNavigator.java:57)
> at org.teiid.query.sql.navigator.PreOrPostOrderNavigator.visit(PreOrPostOrderNavigator.java:194)
> at org.teiid.query.sql.symbol.Function.acceptVisitor(Function.java:169)
> at org.teiid.query.resolver.util.ResolverVisitor.resolveLanguageObject(ResolverVisitor.java:1456)
> at org.teiid.query.resolver.command.UpdateProcedureResolver.resolveStatement(UpdateProcedureResolver.java:234)
> at org.teiid.query.resolver.command.UpdateProcedureResolver.resolveBlock(UpdateProcedureResolver.java:127)
> at org.teiid.query.resolver.command.UpdateProcedureResolver.resolveCommand(UpdateProcedureResolver.java:110)
> at org.teiid.query.resolver.QueryResolver.resolveCommand(QueryResolver.java:282)
> at org.teiid.query.resolver.QueryResolver.resolveCommand(QueryResolver.java:128)
> at org.teiid.dqp.internal.process.Request.resolveCommand(Request.java:282)
> at org.teiid.dqp.internal.process.Request.generatePlan(Request.java:418)
> at org.teiid.dqp.internal.process.Request.processRequest(Request.java:486)
> at org.teiid.dqp.internal.process.RequestWorkItem.processNew(RequestWorkItem.java:660)
> at org.teiid.dqp.internal.process.RequestWorkItem.process(RequestWorkItem.java:339)
> at org.teiid.dqp.internal.process.AbstractWorkItem.run(AbstractWorkItem.java:47)
> at org.teiid.dqp.internal.process.RequestWorkItem.run(RequestWorkItem.java:276)
> at org.teiid.dqp.internal.process.DQPWorkContext.runInContext(DQPWorkContext.java:277)
> at org.teiid.dqp.internal.process.ThreadReuseExecutor$RunnableWrapper.run(ThreadReuseExecutor.java:115)
> at org.teiid.dqp.internal.process.ThreadReuseExecutor$3.run(ThreadReuseExecutor.java:206)
> 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)
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 5 months
[JBoss JIRA] (TEIID-5406) Allow usage of long datatype as the increment parameter in TimestampAdd function
by dalex dalex (JIRA)
dalex dalex created TEIID-5406:
----------------------------------
Summary: Allow usage of long datatype as the increment parameter in TimestampAdd function
Key: TEIID-5406
URL: https://issues.jboss.org/browse/TEIID-5406
Project: Teiid
Issue Type: Enhancement
Components: Query Engine
Affects Versions: 10.2
Environment: teiid-10.2.0 on WildFly Full 11.0.0.Final (WildFly Core 3.0.8.Final)
Reporter: dalex dalex
Assignee: Steven Hawkins
Currently the TIMESTAMPADD(interval, count, timestamp) expects the count parameter to be integer. This is inconsistent with the return value of the TIMSTAMPDIFF function that is long. Thus we cannot take the fraction of the count returned by TIMSTAMPDIFF and submit it to TIMESTAMPADD. Since the SQL_TSI_FRAC_SECOND difference is too large for most human values (and it's the only way to retrieve millis, even though millions of millis), we need a way to submit this data to TIMSTAMPADD.
1. There is an inconsistency when adding 1 billion fractions of a second. Please execute the script below, one adds one billion minus one, the next one exactly 1bln fractions which results in two values, one of which is 1 fraction larger than expected:
{code:sql}
Select TimestampAdd(SQL_TSI_FRAC_SECOND, 999999999, Cast(CurDate() as timestamp))
Union All
Select TimestampAdd(SQL_TSI_FRAC_SECOND, 999999999 + 1, Cast(CurDate() as timestamp));;
{code}
2. Another example:
{code:sql}
Begin
Declare timestamp initialDate = CurDate();
Declare long diff = TimestampDiff(SQL_TSI_FRAC_SECOND, initialDate, TimestampAdd(SQL_TSI_DAY, 1, initialDate));
Declare timestamp back = TimestampAdd(SQL_TSI_FRAC_SECOND, diff, initialDate);
select initialDate, back;
End ;;
{code}
which leads to following error message:
{code:noformat}
2018-07-03 10:10:33,942 WARN [org.teiid.PROCESSOR] (Worker7_QueryProcessorQueue47) 1RBg/ooz5vx7 TEIID30020 Processing exception for request 1RBg/ooz5vx7.27 'TEIID30070 The function
'TimestampAdd(SQL_TSI_FRAC_SECOND, VARIABLES.diff, VARIABLES.initialDate)' is a valid function form, but the arguments do not match a known type signature and cannot be converted usi
ng implicit type conversions.'. Originally QueryResolverException ResolverVisitor.java:757.: org.teiid.api.exception.query.QueryResolverException: TEIID30070 The function 'TimestampA
dd(SQL_TSI_FRAC_SECOND, VARIABLES.diff, VARIABLES.initialDate)' is a valid function form, but the arguments do not match a known type signature and cannot be converted using implicit
type conversions.
at org.teiid.query.resolver.util.ResolverVisitor.resolveFunction(ResolverVisitor.java:757)
at org.teiid.query.resolver.util.ResolverVisitor.visit(ResolverVisitor.java:392)
at org.teiid.query.sql.symbol.Function.acceptVisitor(Function.java:169)
at org.teiid.query.sql.navigator.AbstractNavigator.visitVisitor(AbstractNavigator.java:50)
at org.teiid.query.sql.navigator.PreOrPostOrderNavigator.postVisitVisitor(PreOrPostOrderNavigator.java:57)
at org.teiid.query.sql.navigator.PreOrPostOrderNavigator.visit(PreOrPostOrderNavigator.java:194)
at org.teiid.query.sql.symbol.Function.acceptVisitor(Function.java:169)
at org.teiid.query.resolver.util.ResolverVisitor.resolveLanguageObject(ResolverVisitor.java:1456)
at org.teiid.query.resolver.command.UpdateProcedureResolver.resolveStatement(UpdateProcedureResolver.java:234)
at org.teiid.query.resolver.command.UpdateProcedureResolver.resolveBlock(UpdateProcedureResolver.java:127)
at org.teiid.query.resolver.command.UpdateProcedureResolver.resolveCommand(UpdateProcedureResolver.java:110)
at org.teiid.query.resolver.QueryResolver.resolveCommand(QueryResolver.java:282)
at org.teiid.query.resolver.QueryResolver.resolveCommand(QueryResolver.java:128)
at org.teiid.dqp.internal.process.Request.resolveCommand(Request.java:282)
at org.teiid.dqp.internal.process.Request.generatePlan(Request.java:418)
at org.teiid.dqp.internal.process.Request.processRequest(Request.java:486)
at org.teiid.dqp.internal.process.RequestWorkItem.processNew(RequestWorkItem.java:660)
at org.teiid.dqp.internal.process.RequestWorkItem.process(RequestWorkItem.java:339)
at org.teiid.dqp.internal.process.AbstractWorkItem.run(AbstractWorkItem.java:47)
at org.teiid.dqp.internal.process.RequestWorkItem.run(RequestWorkItem.java:276)
at org.teiid.dqp.internal.process.DQPWorkContext.runInContext(DQPWorkContext.java:277)
at org.teiid.dqp.internal.process.ThreadReuseExecutor$RunnableWrapper.run(ThreadReuseExecutor.java:115)
at org.teiid.dqp.internal.process.ThreadReuseExecutor$3.run(ThreadReuseExecutor.java:206)
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)
{code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 5 months
[JBoss JIRA] (TEIID-2251) All multi-source models share the same metadata
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-2251?page=com.atlassian.jira.plugin... ]
Steven Hawkins resolved TEIID-2251.
-----------------------------------
Resolution: Deferred
Without a major overhaul of the import logic especially when sources are added/removed at runtime, there isn't a great way to do this. If manipulating the import naming is not sufficient (such as errors caused by native type) another workaround is to use a vdb per source and then a multi-source vdb over the source vdbs.
> All multi-source models share the same metadata
> -----------------------------------------------
>
> Key: TEIID-2251
> URL: https://issues.jboss.org/browse/TEIID-2251
> Project: Teiid
> Issue Type: Sub-task
> Components: Query Engine, Server
> Affects Versions: 8.1, 8.2
> Environment: Win XP pro, JBoss AS 7.1.1, JDBC drivers: system-i (jt400 7.8) , MySQL (connector/j 6.5.1)
> Reporter: Dave Stannard
> Assignee: Steven Hawkins
>
> Sharing the same metadata can cause issues, for heterogeneous sources or when attempting to use multi-source for multiple schemas, as described below:
> Teiid issues queries with the catalog and schema of the the primary source. This gives invalid results for all the other sources.
> If the non-primary source connection(s) have authority to access the primary's catalog/schema then duplicated rows are returned to the client.
> If it does *not* have authority then an error results.
> Note: In MySQL this effect can be mitigated by setting useCatalogName=false. This seems to be because the JDBC4DatabaseMetaData.getTables() method does not return a schema; so suppressing the catalog is enough.
> For the System-I whose equivalent getTables() method returns a catalog and schema, I couldn't find a workaround.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 5 months
[JBoss JIRA] (TEIID-4265) Performance issue
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-4265?page=com.atlassian.jira.plugin... ]
Steven Hawkins resolved TEIID-4265.
-----------------------------------
Resolution: Out of Date
[~jolee] I'm willing to say this can be resolved as out of date. With no code changes to explain the observed difference we should move on for now.
> Performance issue
> -----------------
>
> Key: TEIID-4265
> URL: https://issues.jboss.org/browse/TEIID-4265
> Project: Teiid
> Issue Type: Bug
> Components: Query Engine
> Reporter: Juraj Duráni
> Assignee: Steven Hawkins
> Attachments: dv-tpch-2.zip, metadata_ddl.zip, plans_metadata.zip
>
>
> I can see reduce of performance for some kind of queries (see attachment).
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 5 months
[JBoss JIRA] (TEIID-3398) Use Weka algorithm to caculate serializing, deserializing linear regression rate
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-3398?page=com.atlassian.jira.plugin... ]
Steven Hawkins resolved TEIID-3398.
-----------------------------------
Resolution: Deferred
> Use Weka algorithm to caculate serializing, deserializing linear regression rate
> --------------------------------------------------------------------------------
>
> Key: TEIID-3398
> URL: https://issues.jboss.org/browse/TEIID-3398
> Project: Teiid
> Issue Type: Feature Request
> Components: Sizing Application
> Reporter: Kylin Soong
> Assignee: Van Halbert
> Priority: Optional
>
> We have lots of data points {(size i, time i), i = 1, ..., n}, the goal is to find the equation of the straight line like
> time = K * size
> The key is to find the linear regression rate K, current we do not use any algorithm, Weka(http://sourceforge.net/projects/weka/) have algorithm to fine the K, we may use the Weka to enhance Sizing application
> Doc link: http://www.cs.waikato.ac.nz/~ml/weka/documentation.html
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 5 months
[JBoss JIRA] (TEIID-4251) Built in support for Postgres DB as materialization target
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-4251?page=com.atlassian.jira.plugin... ]
Steven Hawkins updated TEIID-4251:
----------------------------------
Fix Version/s: 11.1
> Built in support for Postgres DB as materialization target
> ----------------------------------------------------------
>
> Key: TEIID-4251
> URL: https://issues.jboss.org/browse/TEIID-4251
> Project: Teiid
> Issue Type: Sub-task
> Components: Server
> Reporter: Ramesh Reddy
> Fix For: 11.1
>
>
> If Postgres database is available along with install or assumed that it is available, then some of the materialization task can be automated, like
> - Creation of a common STATUS table
> - Creation of the materilization targets (create views on dbms)
> - On load, on undeploy and load scripts for all the materialization views
> We need to device a way this to be pluggable, such that based on success of this, we can provide additional support for other sources.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 5 months