[JBoss JIRA] (TEIID-4476) Upgrade Cassandra Client library
by Steven Hawkins (Jira)
[ https://issues.jboss.org/browse/TEIID-4476?page=com.atlassian.jira.plugin... ]
Steven Hawkins commented on TEIID-4476:
---------------------------------------
Ramesh, other than the concern about needing to export guava that looks like it should work. In reviewing TEIID-5435, it may have just been limited to the MoreExecutors class (from TEIID-3849) - which could have just as easily not been used.
> Upgrade Cassandra Client library
> --------------------------------
>
> Key: TEIID-4476
> URL: https://issues.jboss.org/browse/TEIID-4476
> Project: Teiid
> Issue Type: Task
> Components: Misc. Connectors
> Reporter: Ramesh Reddy
> Assignee: Kylin Soong
> Priority: Major
> Fix For: 9.2
>
>
> Cassandra client version of the library is 2.1, this needs to be upgraded to the latest version.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 2 months
[JBoss JIRA] (TEIID-5498) Allow the pg layer to work for simple selects with the postgres_fdw
by Steven Hawkins (Jira)
[ https://issues.jboss.org/browse/TEIID-5498?page=com.atlassian.jira.plugin... ]
Steven Hawkins resolved TEIID-5498.
-----------------------------------
Resolution: Done
Simple types and their array variations will work just fine. The standard pg/odbc issues remain:
- the cursor select is under a transaction
- the object type is not supported
- multi-dimensional arrays are not supported
- lobs are inline in the resultset and limited in size
> Allow the pg layer to work for simple selects with the postgres_fdw
> -------------------------------------------------------------------
>
> Key: TEIID-5498
> URL: https://issues.jboss.org/browse/TEIID-5498
> Project: Teiid
> Issue Type: Sub-task
> Components: ODBC
> Reporter: Steven Hawkins
> Assignee: Steven Hawkins
> Priority: Major
> Fix For: 11.2
>
>
> Another avenue for materialization support outlined in TEIID-4251 is to rely upon pg materialization, which would be easiest to setup through their foreign data wrapper. However it expects some additional support for:
> start transaction syntax
> abort transaction
> automatic cleanup of portals/cursors at the end of a transaction
> prepared cursors
> Additionally this will have the same performance issue that we have with declare/fetch initially - that is a cursor requires a transaction, and our current strategy requires pre-buffering the results under a transaction. However since this would only be used for load/refresh that performance hit may be negligible - if now we'd need similar logic to effectively ignore the transaction wrapping.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 2 months
[JBoss JIRA] (TEIID-5499) Add a json type
by Steven Hawkins (Jira)
[ https://issues.jboss.org/browse/TEIID-5499?page=com.atlassian.jira.plugin... ]
Work on TEIID-5499 started by Steven Hawkins.
---------------------------------------------
> Add a json type
> ---------------
>
> Key: TEIID-5499
> URL: https://issues.jboss.org/browse/TEIID-5499
> Project: Teiid
> Issue Type: Feature Request
> Components: Query Engine
> Reporter: Steven Hawkins
> Assignee: Steven Hawkins
> Priority: Major
> Fix For: 11.2
>
>
> The initial design of a json type was a simple extension of the clob type - mostly for runtime differentiation so that parsing could be selectively skipped.
> Since the json type is supported by postgresql we should allow that to be conveyed at least in the odbc metadata - and it would probably be best to have a full json type.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 2 months
[JBoss JIRA] (TEIID-5499) Add a json type
by Steven Hawkins (Jira)
Steven Hawkins created TEIID-5499:
-------------------------------------
Summary: Add a json type
Key: TEIID-5499
URL: https://issues.jboss.org/browse/TEIID-5499
Project: Teiid
Issue Type: Feature Request
Components: Query Engine
Reporter: Steven Hawkins
Assignee: Steven Hawkins
Fix For: 11.2
The initial design of a json type was a simple extension of the clob type - mostly for runtime differentiation so that parsing could be selectively skipped.
Since the json type is supported by postgresql we should allow that to be conveyed at least in the odbc metadata - and it would probably be best to have a full json type.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 2 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 commented on TEIID-4251:
---------------------------------------
> fail fast? the fdw seems to hang if the remote server is not available, but that shouldn't really be a concern
This seems to only happen with initial usage. Subsequent access must be using a saved connection and will immediately fail if Teiid is unavailable. I'm not clear, but I don't think a pool is used from glancing at the source.
> 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
> Assignee: Steven Hawkins
> Priority: Major
> Fix For: 11.2
>
>
> 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.12.1#712002)
6 years, 2 months
[JBoss JIRA] (TEIID-5472) Clean up window function project node implementation
by Steven Hawkins (Jira)
[ https://issues.jboss.org/browse/TEIID-5472?page=com.atlassian.jira.plugin... ]
Steven Hawkins resolved TEIID-5472.
-----------------------------------
Resolution: Done
Marking as resolved until there is an impetus to revisit. The three remaining items are:
- moving any of the aggregate value computation onto the aggregate classes, which can be done for lead/lag and the distribution functions by using the frame based logic. That however comes at a performance cost
- adding or changing the logic to work over the specification sorts such that we can immediately output the row results, rather than rebuilding by iterating over the input again.
- Remove the specification distinction between row/range processing so that they can be computed together for the same specification
> Clean up window function project node implementation
> ----------------------------------------------------
>
> Key: TEIID-5472
> URL: https://issues.jboss.org/browse/TEIID-5472
> Project: Teiid
> Issue Type: Quality Risk
> Components: Query Engine
> Reporter: Steven Hawkins
> Assignee: Steven Hawkins
> Priority: Major
> Fix For: 11.2
>
>
> The initial implementation of window functions did not allow for a frame clause and specifically separated the logic of creating row and range values. Now that the logic is more complete we should remove some of the initial design aspects.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 2 months
[JBoss JIRA] (TEIID-5497) MetadataRepository can't be implemented
by Steven Hawkins (Jira)
[ https://issues.jboss.org/browse/TEIID-5497?page=com.atlassian.jira.plugin... ]
Steven Hawkins resolved TEIID-5497.
-----------------------------------
Fix Version/s: 11.2
Resolution: Done
Changed back to an interface and updated the docs / archetype. This may be a small breaking change for someone using this mechanism with embedded, but it's an easy api change.
Also allowed for a deployment based jar to be used rather than a full module to make it easier to add an arquillian test.
> MetadataRepository can't be implemented
> ---------------------------------------
>
> Key: TEIID-5497
> URL: https://issues.jboss.org/browse/TEIID-5497
> Project: Teiid
> Issue Type: Enhancement
> Affects Versions: 10.2.2
> Reporter: Don Krapohl
> Assignee: Steven Hawkins
> Priority: Major
> Labels: metadata, teiid-engine
> Fix For: 11.2
>
>
> I am unable to extend the MetadataRepository class as shown in the Teiid documentation. Per [~rareddy] the class is now abstract (public abstract class MetadataRepository<F,C>) and can't be implemented through the service loader. I'd like to see if you could implement a mechanism that allows custom metadata repositories again.
> Ref: https://developer.jboss.org/thread/278855
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 2 months
[JBoss JIRA] (TEIID-4489) Adjust defaults and use of 1 to 10 data sources to recommend the SMALL size
by Van Halbert (Jira)
[ https://issues.jboss.org/browse/TEIID-4489?page=com.atlassian.jira.plugin... ]
Van Halbert closed TEIID-4489.
------------------------------
Resolution: Won't Do
> Adjust defaults and use of 1 to 10 data sources to recommend the SMALL size
> ---------------------------------------------------------------------------
>
> Key: TEIID-4489
> URL: https://issues.jboss.org/browse/TEIID-4489
> Project: Teiid
> Issue Type: Enhancement
> Components: Sizing Application
> Affects Versions: 9.x
> Reporter: Van Halbert
> Assignee: Van Halbert
> Priority: Major
> Fix For: 11.x
>
>
> Based on recommendations:
> small : 16 cores, with at least 32 GB RAM. 2 DV instances. (small means may be 5 ~10 sources, rows into millions, YMMV)
> medium : 32 cores with 64 GB RAM, 4 DV instances. (medium means may be 10 ~ 20 sources, rows into multi-millions, YMMV)
> Large: custom
> The defaults in the sizing applications, along with selecting 1 to 10 data sources, should result in the SMALL recommendation. It should be clear to indicate the number of instances and the size recommendation per instance.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 2 months
[JBoss JIRA] (TEIID-3683) Enhance the formula for caculating core size
by Van Halbert (Jira)
[ https://issues.jboss.org/browse/TEIID-3683?page=com.atlassian.jira.plugin... ]
Van Halbert closed TEIID-3683.
------------------------------
Resolution: Won't Do
> Enhance the formula for caculating core size
> --------------------------------------------
>
> Key: TEIID-3683
> URL: https://issues.jboss.org/browse/TEIID-3683
> Project: Teiid
> Issue Type: Enhancement
> Components: Sizing Application
> Reporter: Kylin Soong
> Assignee: Van Halbert
> Priority: Minor
> Fix For: 11.x
>
> Attachments: sizing-tools-cores.png
>
>
> I think we can consider to enhance in the following aspects:
> 1. Q7 is hard for user to input
> Q7 need some pre-test or run sample query via POC, this not easy for user to input, also they may feels confused.
> 2. How to caculate core size?
> Current we consider through serialize/deserialize, the linear serialize/deserialize percentage get from trial in my local pc, this may need more test/review.
> 3. Whether we can use runnable app replace Web UI
> If use runnable app like AdminShell, most of questions in attached png can cacualate and get a precise input,
> Any idea/advice for this?
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 2 months