db-derby-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache Wiki <wikidi...@apache.org>
Subject [Db-derby Wiki] Update of "OptimizerTableNumbers" by BryanPendleton
Date Fri, 29 Sep 2006 02:59:12 GMT
Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Db-derby Wiki" for change notification.

The following page has been changed by BryanPendleton:

The comment on the change is:
Add Army's additional notes about table number -1.

  If the optimizer then decides to use an index for T1, the table number doesn't change--the
optimizer just decides that for "the FromBaseTable whose table number is 0 we will use an
index".  In fact, once assigned, the table number for a specific FromTable remains the same
for the duration of the compilation of the statement.
+  * Under what circumstances will a table number be -1?
+ The only time a FromTable's table number can be -1 during optimization is if it is in fact
a ProjectRestrictNode with a non-FromTable subquery as its child.
+ There are a number of classes that extend FromTable. For many of these classes, table numbers
are always set during binding (and thus will not be -1 when it comes time to optimize)
+ In some cases, classes which extend FromTable are only instantiated AFTER optimization has
completed, and thus even though their table numbers can be -1, that won't affect optimization.
For example,  IndexToBaseRowNode, and  SingleChildResultSetNode.
+ There are two subclasses of FromTable that can be instantiated during preprocessing but
that may not have their table numbers set (these are the ones of interest to the current discussion):
+  * ProjectRestrictNode:
+   If created during preprocessing, table number will only be set in
+   FromSubquery.extractSubquery(); in all other cases it will remain -1.
+  * NormalizeResultSetNode:
+   Instantiated during bind phase for InsertNode and UpdateNode
+   but table number is not set.  So it will be -1.  However,
+   a NormalizeresultSetNode never appears in an optimizer's
+   optimizableList, and thus such a node will never actually
+   be optimized.

View raw message