[JBoss JIRA] (TEIID-1813) EDS performance tests shows a performance degradation against SOA-P 5.1.0.GA in case of selecting from XML datasource
by Steven Hawkins (Issue Comment Edited) (JIRA)
[ https://issues.jboss.org/browse/TEIID-1813?page=com.atlassian.jira.plugin... ]
Steven Hawkins edited comment on TEIID-1813 at 11/7/11 8:59 AM:
----------------------------------------------------------------
This seems way too late in the release cycle to consider as a blocker. For performance related feedback to be useful, it needs to come much sooner. The turnaround time on this is unknown (we'll at least need the test setup and what specific test is being run for this XML case). Also if this is a parsing or xmltable path, the performance is largely out of our control as there was a forced Saxon upgrade between the EDS versions.
was (Author: shawkins):
This seem way to late in the release cycle to consider as a blocker. For performance related feedback to be useful, it needs to come much sooner. The turnaround time on this is unknown (we'll at least need the test setup and what specific test is being run for this XML case). Also if this is a parsing or xmltable path, the performance is largely out of our control as there was a forced Saxon upgrade between the EDS versions.
> EDS performance tests shows a performance degradation against SOA-P 5.1.0.GA in case of selecting from XML datasource
> ----------------------------------------------------------------------------------------------------------------------
>
> Key: TEIID-1813
> URL: https://issues.jboss.org/browse/TEIID-1813
> Project: Teiid
> Issue Type: Bug
> Components: Server
> Affects Versions: 7.4.1
> Reporter: Pavel Macik
> Assignee: Van Halbert
> Priority: Blocker
>
> The eds_xmlfile_select scenario shows ~30% performance degradation in select queries from XML datasource.
> See the "(EDS) Files select - Charts" sheet of the document at [1] for details.
> [1] https://docspace.corp.redhat.com/docs/DOC-56368
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 10 months
[JBoss JIRA] (TEIID-1726) Requesting ability to add/use Oracle hints in EDS
by Steven Hawkins (Commented) (JIRA)
[ https://issues.jboss.org/browse/TEIID-1726?page=com.atlassian.jira.plugin... ]
Steven Hawkins commented on TEIID-1726:
---------------------------------------
I had missed your earlier question on short term advice. Yes you can add dummy must pushdown udfs as a way to contribute a hint to the source. Having the function in the WHERE clause is the best place to help ensure pushdown.
Something like "... WHERE CUSTOMHINT(oracle-col,'y')=1". Note that the function or the predicate must reference a source column so that we know where to push the function to. In that regard, this approach has a small advantage over the approach outlined in the previous comment. The user would need to be careful to ensure that the UDF is only used in the where clause and only as a conjunct - it wouldn't make any sense to do something like "WHERE x=y OR CUSTOMHINT..."
In your augmented translator you would then modify the query criteria by removing any instance of CUSTOMHINT and then alter the getSourceComment method (assuming your starting with the Oracle or JDBCExecutionFactory). You may even add a FunctionModifier for the hint udf(s) that would raise an exception to indicate a usage error - as it should have already been removed.
> Requesting ability to add/use Oracle hints in EDS
> -------------------------------------------------
>
> Key: TEIID-1726
> URL: https://issues.jboss.org/browse/TEIID-1726
> Project: Teiid
> Issue Type: Feature Request
> Components: Server
> Affects Versions: 7.4.1
> Reporter: Debbie Steigner
> Assignee: Steven Hawkins
> Fix For: 7.6
>
>
> Requesting the ability to use Oracle hints inside virtual transformations and enduser queries in EDS and Teiid Designer
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 11 months
[JBoss JIRA] (TEIID-1726) Requesting ability to add/use Oracle hints in EDS
by Steven Hawkins (Commented) (JIRA)
[ https://issues.jboss.org/browse/TEIID-1726?page=com.atlassian.jira.plugin... ]
Steven Hawkins commented on TEIID-1726:
---------------------------------------
Here's what I'm working towards:
The initial implementation will be a multi-hint container hint of the form "sh(:'arg')? translator-name:'arg' ...", where the hint args follow the parsing rules for string literals. For example:
select /*+ sh:'foo' oracle:'all_rows' */ x, y ...
Since we are already breaking encapsulation, there is no direct support for referencing Teiid columns/tables. It is expected that the user will know the appropriate block name and or source names that their hint affects. If a user wishes they can expand on this technique to include fully qualified Teiid names in the hint and then use the runtime metadata facility to lookup appropriate source metadata (and they would also potentially need the appropriate correlation name). Note that we could leave off the notion of a general hint for now, but it seems useful to have a single place to specify a hint that can be passed to all sources.
The translators will receive the source hint (both the general sh argument if specified and the translator specific if available) from the top most level query providing a hint. New methods may be needed on the ExecutionContext to support this. Hints from a subquery, or joined/unioned view will be ignored.
Only the oracle translator will do anything with these hints to begin with. If a hint is specified, then it will be placed in the source query surrounded by /*+ */.
These source hints will be expected to appear after the first token in the query and can appear on user queries, view definitions, or in virtual procedure command statements (a minor amount of additional effort would also allow them to appear in arbitrary virtual procedure expressions).
Also available in 7.6 is support for native-query metadata on source tables/procedures - see TEIID-669 and the reference.
Let me know if you have any concerns.
> Requesting ability to add/use Oracle hints in EDS
> -------------------------------------------------
>
> Key: TEIID-1726
> URL: https://issues.jboss.org/browse/TEIID-1726
> Project: Teiid
> Issue Type: Feature Request
> Components: Server
> Affects Versions: 7.4.1
> Reporter: Debbie Steigner
> Assignee: Steven Hawkins
> Fix For: 7.6
>
>
> Requesting the ability to use Oracle hints inside virtual transformations and enduser queries in EDS and Teiid Designer
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 11 months
[JBoss JIRA] (TEIID-1811) Deleting a VDB from inventory does not remove it
by Van Halbert (Updated) (JIRA)
[ https://issues.jboss.org/browse/TEIID-1811?page=com.atlassian.jira.plugin... ]
Van Halbert updated TEIID-1811:
-------------------------------
Fix Version/s: 7.6
Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=739789 (was: https://bugzilla.redhat.com/show_bug.cgi?id=739789)
> Deleting a VDB from inventory does not remove it
> ------------------------------------------------
>
> Key: TEIID-1811
> URL: https://issues.jboss.org/browse/TEIID-1811
> Project: Teiid
> Issue Type: Bug
> Components: Tools
> Affects Versions: 7.6
> Environment: JON 2.4.1/3.0.0, PostgreSQL 8.4.8, OpenJDK 1.6.0, SOA-P/EDS
> 5.1.0/5.2.0 GA
> Reporter: Pavel Kralik
> Assignee: Ted Jones
> Fix For: 7.6
>
>
> Using JON 2.4, deleting a VDB through JON GUI inventory removes the vdb from
> the EDS instance, but does not remove it from inventory. Instead, it shows the
> vdb as unavailable.
> How reproducible:
> Steps to Reproduce:
> 1. Deploy a vdb to EDS
> 2. Have agent report vdb to JON, verify in GUI
> 3. In JON inventory, delete the vdb
> Actual results:
> VDB is removed from physical server but remains in JON inventory, just as
> disabled. It remains there even after running 'discovery -f' from the agent
> console.
> Expected results:
> VDB is removed from physical server and removed from JON inventory.
> Additional info:
> https://bugzilla.redhat.com/show_bug.cgi?id=739789
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 11 months