[JBoss JIRA] (TEIID-4858) hive translator is extremely slow
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-4858?page=com.atlassian.jira.plugin... ]
Steven Hawkins updated TEIID-4858:
----------------------------------
Issue Type: Quality Risk (was: Bug)
Fix Version/s: 9.3
We need to make a determination in 9.3 what the resolution will be here - default to order by support disabled, document that it may cause issues, delve further to determine what is happening, etc.
> hive translator is extremely slow
> ---------------------------------
>
> Key: TEIID-4858
> URL: https://issues.jboss.org/browse/TEIID-4858
> Project: Teiid
> Issue Type: Quality Risk
> Components: JDBC Connector
> Affects Versions: 8.12.9.6_3
> Environment: Tested against JDV 6.3.4 and the Cloudera quickstart 5.8 VM with the Cloudera sample data loaded into hive
> Reporter: Michael Echevarria
> Assignee: Steven Hawkins
> Fix For: 9.3
>
> Attachments: fast.log, override1.png, override2.png, slow.log
>
>
> When querying a table through the hive translator the results take close to 30 seconds to return.
> When querying a table through jdbc default results take under 1 second to return.
> Both use the same underlying jboss server datasource.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 8 months
[JBoss JIRA] (TEIID-4889) Separate commons-net and mongo-java-driver from api module
by Kylin Soong (JIRA)
[ https://issues.jboss.org/browse/TEIID-4889?page=com.atlassian.jira.plugin... ]
Kylin Soong resolved TEIID-4889.
--------------------------------
Resolution: Done
> Separate commons-net and mongo-java-driver from api module
> ----------------------------------------------------------
>
> Key: TEIID-4889
> URL: https://issues.jboss.org/browse/TEIID-4889
> Project: Teiid
> Issue Type: Quality Risk
> Components: Build/Kits
> Affects Versions: 9.3
> Reporter: Kylin Soong
> Assignee: Kylin Soong
> Fix For: 9.3
>
>
> {code}
> file/api/
> └── main
> ├── commons-net-3.5.jar
> ├── file-api-9.3.0.Beta2-SNAPSHOT.jar
> └── module.xml
> mongodb/api/
> └── main
> ├── module.xml
> ├── mongodb-api-9.3.0.Beta2-SNAPSHOT.jar
> └── mongo-java-driver-2.13.1.jar
> {code}
> As above snippets, commons-net and mongo-java-driver are packaged together with api module, some times feel confused if set up auto-detect and create module in runtime.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 8 months
[JBoss JIRA] (TEIID-4867) Loosen up OData4 URL validation or parsing
by Johnathon Lee (JIRA)
[ https://issues.jboss.org/browse/TEIID-4867?page=com.atlassian.jira.plugin... ]
Johnathon Lee updated TEIID-4867:
---------------------------------
Fix Version/s: 8.12.11.6_3
> Loosen up OData4 URL validation or parsing
> ------------------------------------------
>
> Key: TEIID-4867
> URL: https://issues.jboss.org/browse/TEIID-4867
> Project: Teiid
> Issue Type: Bug
> Components: OData
> Affects Versions: 8.12.8.6_3
> Environment: JDV 6.3.2
> Windows 7
> Reporter: Steve Tran
> Assignee: Johnathon Lee
> Fix For: 8.12.x-6.4, 8.12.11.6_3
>
>
> I'm accessing my JDV table via OData4 through Salesforce's UI builder. The salesforce engine itself is creating the OData calls, and whenever a $filter is needed with multiple columns, it looks like salesforce pads the column name with a space in front and behind. That'll make the URL look like ...$filter={color:red}%20{color}ColumnA{color:red}%20{color}eq%20123%20and{color:red}%20{color}ColumnB{color:red}%20{color}eq...
> The first space right after the $filter= throws off the JDV engine as it thinks it's a malformed URL - which I guess it is. The thing is when I tested it via the OData2 interface, it accepted it just fine. I'm not sure if the OData4 specifications explicitly state in terms of the URL, so it could be anybody's bug. Perhaps we could make JDV a little more forgiving and trim the spaces after un-URL-encoding the URI.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 8 months
[JBoss JIRA] (TEIID-4881) Better account for differences between ddl and vdb.xml vdbs
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-4881?page=com.atlassian.jira.plugin... ]
Steven Hawkins commented on TEIID-4881:
---------------------------------------
Made a commit to change the metadata load and ddl processing to be performed sequentially after the parsing of the vdb structure. This two phase approach keeps thing relatively consistent with the current logic. This loosened the previous restriction on the ddl somewhat, which I'll update in the docs. However it also means that for now metadata caching is not supported - as that was tied to the notion of metadata loading for a schema. It also means that load will not wait for source availability or retry if there is an issue with getting a connection. All of which make the load look more like the behavior of Teiid embedded.
> Better account for differences between ddl and vdb.xml vdbs
> -----------------------------------------------------------
>
> Key: TEIID-4881
> URL: https://issues.jboss.org/browse/TEIID-4881
> Project: Teiid
> Issue Type: Task
> Components: Query Engine
> Affects Versions: 9.2
> Reporter: Steven Hawkins
> Assignee: Steven Hawkins
> Fix For: 9.3
>
>
> In several aspects the metadata systems are different, which is touched on in TEIID-4536
> This issue will cover making them function as similarly as possible and to also document the ways in which they are different.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 8 months
[JBoss JIRA] (TEIID-4885) Costing issues
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-4885?page=com.atlassian.jira.plugin... ]
Steven Hawkins resolved TEIID-4885.
-----------------------------------
Resolution: Done
Addressed the issues and changed the predicate costing logic to use a smoother estimate for high ndv values.
> Costing issues
> --------------
>
> Key: TEIID-4885
> URL: https://issues.jboss.org/browse/TEIID-4885
> Project: Teiid
> Issue Type: Quality Risk
> Components: Query Engine
> Reporter: Steven Hawkins
> Assignee: Steven Hawkins
> Fix For: 9.3
>
>
> There were several deficiencies introduced with TEIID-4332 -
> In some circumstances very low ndv values on the large side of a join would cause a dependent join in an unexpected direction.
> The row estimate derived for a join without ndv information would tend to be too low, which would have a cumulative effect through further joins.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 8 months