[ http://issues.apache.org/jira/browse/DERBY-1866?page=comments#action_12438527 ] A B commented on DERBY-1866: ----------------------------
> You mentioned one case where this can be -1 on your earlier reply, > but I was wondering if there are any other cases where table number > can be -1 since you mentioned there are some cases. Sorry for misunderstanding your question. When I wrote "some" cases I intended that to mean that there are "some" cases where a ProjectRestrictNode (PRN)'s tableNumber can be -1 (namely, if it's child is an Optimizable). Since that's the only time I've ever seen a negative table number when tracing through code, I've been assuming that's the only case when it can happen. But inspired by your question, I decided to do a search through the codeline to see if there are any other situations when a table number can be -1 during optimization. (Note: the emphasis here is on optimization, since that's the area of code at issue with this Jira). The only other case I found was for NormalizeResultSetNode, which is created for InsertNode and UpdateNode. But NormalizeResultSetNodes are generated on top of a ResultSetNode to be optimized--they are not themselves optimized, which means that we wouldn't ever get to the code in d1866_v1.patch with a "curTable" that is a NormalizeResultSetNode. So even though a NormalizeRSN can have a negative table number, that doesn't affect the proposed changes. Thus based on my understanding, 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. As a minor sort of sanity check for these results, I put a System.out in OptimizerImpl to print a message if we ever saw an Optimizable that had a negative table number but that was not a PRN, and then I ran derbylang. The message was never printed. This doesn't "prove" anything in particular, but it does lend evidence to the results of my code search... --- Details on my search: Below are the classes I found that extend FromTable. I looked to see 1) where the various classes were instantiated, and 2) where their table numbers were set (if at all). The breakdown based on my searching is as follows: FromTables whose table numbers are always set during binding (and thus will not be -1 when it comes time to optimize): CurrentOfNode FromBaseTable FromSubquery FromVTI RowResultSetNode TableOperatorNode ->JoinNode (via inheritance from TableOp) --->HalfOuterJoinNode (inheritance from TableOp) ->SetOperatorNode (inheritance from TableOp) --->IntersectOrExceptNode (inheritance from TableOp) --->UnionNode (inheritance from TableOp) FromTables that are only instantiated AFTER optimization has completed, and thus even though their table numbers can be -1, that won't affect optimization. IndexToBaseRowNode SingleChildResultSetNode ->DistinctNode ->GroupByNode ->HashTableNode ->MaterializeResultSetNode ->OrderByNode ->ScrollInsensitiveResultSetNode FromTables 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. ---- Hopefully that's more in line with what you were asking? Thanks again for the review and great questions... > Assert failure in sane mode for queries that used to work in 10.1.2.1 > --------------------------------------------------------------------- > > Key: DERBY-1866 > URL: http://issues.apache.org/jira/browse/DERBY-1866 > Project: Derby > Issue Type: Bug > Components: SQL > Affects Versions: 10.1.3.2, 10.1.4.0, 10.2.1.5 > Reporter: A B > Assigned To: A B > Fix For: 10.2.2.0, 10.3.0.0 > > Attachments: d1866_v1.patch, derby.log, repro.sql > > > Derby-1777 gives a database and a small program called "ViewerInit" that > prepares a bunch of large queries involving nested subqueries, unions, and > join predicates. The actual bug described in DERBY-1777 is an NPE, and > that's what the patch for DERBY-1777 addresses. > However, once the NPEs are fixed, some of the queries in that same program > now fail with ASSERT failures when running in SANE mode; this Jira issue is > for addressing those assert failures. > While this does constitute a regression, I don't know yet what the root cause > of the problem is, so I hesitate to make it a 10.2 blocker--hence urgency is > "Normal". I'm still investigating the queries to try to track down where the > problem is, but all I've been able to deduce so far is that a) the assertion > occurs for a scoped predicate and thus the pushing of join predicates into > UNIONs is somehow involved, and b) in INSANE mode the query compiles without > problem and appears (based on some early and very incomplete testing) to > execute without problem. But more investigation is required to determine if > the execution/results are actually correct, and to understand more about why > the assertion is being thrown. > I'm marking the fixin as 10.2.2.0 for now since I don't enough to make this a > blocker for 10.2.1. Hopefully more info will be forthcoming... -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
