[teiid-commits] teiid SVN: r3052 - in trunk: documentation/developer-guide/src/main/docbook/en-US/content and 1 other directories.

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>