Author: shawkins
Date: 2011-04-02 08:21:04 -0400 (Sat, 02 Apr 2011)
New Revision: 3052
Modified:
trunk/build/kits/jboss-container/teiid-releasenotes.html
trunk/documentation/developer-guide/src/main/docbook/en-US/content/translator-api.xml
trunk/documentation/reference/src/main/docbook/en-US/content/translators.xml
Log:
TEIID-1533 updating the docs/release notes
Modified: trunk/build/kits/jboss-container/teiid-releasenotes.html
===================================================================
--- trunk/build/kits/jboss-container/teiid-releasenotes.html 2011-04-02 11:57:44 UTC (rev
3051)
+++ trunk/build/kits/jboss-container/teiid-releasenotes.html 2011-04-02 12:21:04 UTC (rev
3052)
@@ -40,10 +40,16 @@
<LI><B>Optional Join Enhancements</B> - the optional join hint no
longer requires the use of ANSI joins and can will not remove optional bridging tables
that are used by two other tables that are required.
<LI><B>InterSystems Cache</B> - InterSystems Cache database translator
is now available to use as supported source under Teiid.
<LI><B>userRequestSourceConcurrency</B> - was added to control the
number of concurrent source queries allowed for each user request.
- <LI><B>Dependent Join Improvements</B> - dependent join analysis and
costing in general was improved to consider dependent joins earlier in planning.
<LI><B>Memory Management Improvements</B> - maxReserveBatchColumns and
maxProcessingBatchesColumns will be default be determined automatically and will more
reliably prevent memory issues. See the admin guide for more.
<LI><B>Subquery optimization control</B> - added the MJ and NO_UNNEST
hints and the org.teiid.subqueryUnnestDefault system property to control the optimization
of subqueries to traditional joins or to a merge join implemenation of a semijoin or
antijoin.
- <LI><B>Local connection threads </B> - local connection calling
threads will be used to process work rather than using an engine thread. This helps
decouple the configuration of maxThreads.
+ <LI><B>Local connection threads</B> - local connection calling threads
will be used to process work rather than using an engine thread. This helps decouple the
configuration of maxThreads.
+ <LI><B>Dependent Join Improvements</B> - several major improvements
were made to increase performance and develop better plans.
+ <UL>
+ <LI><B>Improved Planning</B> - the decision to create a dependent
join is now considered earlier in planning and is much more effective for dependent joins
involving multiple unrelated independent tables.
+ <LI><B>IN predicate splitting</B> - the planner can now split large
dependent IN predicates into multiple IN predicates, which is controlled by the translator
property MaxDepdendentInPredicates. This allows for much larger dependent joins to be
performed as a single query.
+ <LI><B>Dependent query parallization</B> - when multiple dependent
queries are still required, then they will be run in parallel (up to
MaxUserSourceRequestConcurrency), rather than sequentially.
+ </UL>
+ <LI><B>Enhanced Sort Join</B> - the partitioned merge join was
replaced with an enhanced sort join. The enhanced sort join will use the actual row
counts from each side of the relation to perform a index based join if one side is small
enough, a partial sort of the larger side and a repeated merge join if the tuples are
unbalanced but one side is not small enough to form an index, or a standard sort merge
join if the tuples are balanced.
</UL>
<h2><a name="Compatibility">Compatibility
Issues</a></h2>
Modified:
trunk/documentation/developer-guide/src/main/docbook/en-US/content/translator-api.xml
===================================================================
---
trunk/documentation/developer-guide/src/main/docbook/en-US/content/translator-api.xml 2011-04-02
11:57:44 UTC (rev 3051)
+++
trunk/documentation/developer-guide/src/main/docbook/en-US/content/translator-api.xml 2011-04-02
12:21:04 UTC (rev 3052)
@@ -1329,6 +1329,11 @@
IN criteria. This is an important constraint as an IN criteria is
frequently used to pass criteria between one source and another using
a dependent join.</para>
+ <para>The method
<code>ExecutionFactory.getMaxDependentInPredicates()</code> is
+ used to specify the maximum number of IN predicates (of at most MaxInCriteriaSize)
that can be passed
+ as part of a dependent join. For example if there are 10000 values to pass as part of
the dependent join
+ and a MaxInCriteriaSize of 1000 and a MaxDependentInPredicates setting of 5, then the
+ dependent join logic will form two source queries each with 5 IN predicates of 1000
values each combined by OR.</para>
<para>The method <code>ExecutionFactory.getMaxFromGroups()</code> can
be used
to specify the maximum number of FROM Clause groups that can used in a
join. -1 indicates there is no limit.</para>
Modified: trunk/documentation/reference/src/main/docbook/en-US/content/translators.xml
===================================================================
---
trunk/documentation/reference/src/main/docbook/en-US/content/translators.xml 2011-04-02
11:57:44 UTC (rev 3051)
+++
trunk/documentation/reference/src/main/docbook/en-US/content/translators.xml 2011-04-02
12:21:04 UTC (rev 3052)
@@ -114,6 +114,12 @@
<entry>If in criteria are supported, defines what the
maximum number of in entries are per predicate. -1 indicates no limit.</entry>
<entry>-1</entry>
</row>
+ <row>
+ <entry>MaxDependentInPredicates</entry>
+ <entry>If in criteria are supported, defines what the
maximum number of predicates that can be used for a dependent join.
+ Values less than 1 indicate to use only one in predicate per
dependent value pushed (which matches the pre-7.4 behavior).</entry>
+ <entry>-1</entry>
+ </row>
</tbody>
</tgroup>
</table>
Show replies by date