public final Class Predicate

If this predicate's operator is a BinaryRelationalOperatorNode, then look at the operands and return a new, equivalent predicate that is "scoped" to the received ResultSetNode. By "scoped" we mean that the operands, which shold be column references, have been mapped to the appropriate result columns in the received RSN. This is useful for pushing predicates from outer queries down into inner queries, in which case the column references need to be remapped. For example, let V1 represent select i,j from t1 UNION select i,j from t2 and V2 represent select a,b from t3 UNION select a,b from t4 Then assume we have the following query: select * from V1, V2 where V1.j = V2.b Let's further assume that this Predicate object represents the "V1.j = V2.b" operator and that the childRSN we received as a parameter represents one of the subqueries to which we want to push the predicate; let's say it's: select i,j from t1 Then this method will return a new predicate whose binary operator represents the expression "T1.j = V2.b" (that is, V1.j will be mapped to the corresponding column in T1). For more on how that mapping is made, see the "getScopedOperand()" method in BinaryRelationalOperatorNode.java. ASSUMPTION: We should only get to this method if we know that at least one operand in this predicate can and should be mapped to the received childRSN. For an example of where that check is made, see the pushOptPredicate() method in SetOperatorNode.java.

Parameters

parentRSNsTables:JBitSet

Set of all table numbers referenced by the ResultSetNode that is _parent_ to the received childRSN. We need this to make sure we don't scope the operands to a ResultSetNode to which they don't apply.

childRSN:ResultSetNode

The result set node for which we want to create a scoped predicate.

whichRC:int[]

If not -1 then this tells us which ResultColumn in the received childRSN we need to use for the scoped predicate; if -1 then the column position of the scoped column reference will be stored in this array and passed back to the caller.

Returns:Predicate

A new predicate whose operands have been scoped to the received childRSN.

If this predicate corresponds to an IN-list, return the underlying InListOperatorNode from which it was built. There are two forms to check for: 1. This predicate is an IN-list "probe predicate", in which case the underlying InListOpNode is stored within the binary relational operator that is the left operand of this predicate's AND node. 2. This predicate corresponds to an IN-list that could _not_ be transformed into a "probe predicate" (i.e. the IN-list contains one or more non-parameter, non-constant values). In that case the underlying InListOpNode is simply the left operand of this predicate's AND node. If this predicate does not correspond to an IN-list in any way, this method will return null.

Does the work of getSourceInList() above, but can also be called directly with an argument to indicate whether or not we should limit ourselves to probe predicates.

Parameters

probePredOnly:boolean

If true, only get the source IN list for this predicate *if* it is an IN-list probe predicate. If false, return the underlying InListOperatorNode (if it exists) regardless of whether this is a probe predicate or an un-transformed IN-list pred.

Returns:InListOperatorNode

Underlying InListOp for this predicate (depending on the value of probePredOnly), or null if this predicate does not correspond to an IN-list in any way.

Return whether or not this predicate is an IN-list probe predicate.

Is this predicate a join predicate? In order to be so, it must be a binary relational operator node that has a column reference on both sides.

Returns:boolean

Whether or not this is a join predicate.

Return whether or not this predicate corresponds to a legitimate relational operator.

Returns:boolean

False if there is no relational operator for this predicate OR if this predicate is an internal "probe predicate" (in which case it "looks" like we have a relational operator but in truth it's a disguised IN-list operator). True otherwise.

Return whether or not this predicate is a scoped copy of another predicate.

Return true if this predicate is scoped AND the scoped operand is a ColumnReference that points to a source result set. If the scoped operand is not a ColumnReference that points to a source result set then it must be pointing to some kind of expression, such as a literal (ex. 'strlit'), an aggregate value (ex. "count(*)"), or the result of a function (ex. "sin(i)") or operator (ex. "i+1"). This method is used when pushing predicates to determine how far down the query tree a scoped predicate needs to be pushed to allow for successful evaluation of the scoped operand. If the scoped operand is not pointing to a source result set then it should not be pushed any further down tree. The reason is that evaluation of the expression to which the operand is pointing may depend on other values from the current level in the tree (ex. "sin(i)" depends on the value of "i", which could be a column at the predicate's current level). If we pushed the predicate further down, those values could become inaccessible, leading to execution-time errors. If, on the other hand, the scoped operand *is* pointing to a source result set, then we want to push it further down the tree until it reaches that result set, which allows evaluation of this predicate to occur as close to store as possible. This method doesn't actually do the push, it just returns "true" and then the caller can push as appropriate.

Indicate that this predicate is a scoped copy of some other predicate (i.e. it was created as the result of a call to getPredScopedForResultSet() on some other predicate).

Determine whether or not this predicate is eligible for push-down into subqueries. Right now the only predicates we consider to be eligible are those which 1) are Binary Relational operator nodes and 2) have a column reference on BOTH sides, each of which has a reference to a base table somewhere beneath it.

Returns:boolean

Whether or not this predicate is eligible to be pushed into subqueries.

When remapping a "normal" (i.e. non-scoped) predicate both of the predicate's operands are remapped and that's it. But when remapping a scoped predicate, things are slightly different. This method handles remapping of scoped predicates. We know that, for a scoped predicate, exactly one operand has been scoped for a specific target result set; the other operand is pointing to some other instance of FromTable with which the target result set is to be joined (see getScopedOperand() in BinaryRelationalOperatorNode.java). For every level of the query through which the scoped predicate is pushed, we have to perform a remap operation of the scoped operand. We do *not*, however, remap the non-scoped operand. The reason is that the non-scoped operand is already pointing to the result set against which it must be evaluated. As the scoped predicate is pushed down the query tree, the non-scoped operand should not change where it's pointing and thus should not be remapped. For example, assume we have a query whose tree has the following form: SELECT[0] / \ PRN PRN | | SELECT[4] UNION | / \ PRN SELECT[1] SELECT[2] | | | [FBT:T1] PRN PRN | | SELECT[3] [FromBaseTable:T2] | PRN | [FromBaseTable:T3] Assume also that we have some predicate "SELECT[4].i = .j". If the optimizer decides to push the predicate to the UNION node, it (the predicate) will be scoped to the UNION's children, yielding something like "SELECT[4].i = SELECT[1].j" for the left child and "SELECT[4].i = SELECT[2].j" for the right child. These scoped predicates will then be pushed to the PRNs above SELECT[3] and T2, respectively. As part of that pushing process a call to PRN.pushOptPredicate() will occur, which brings us to this method. So let's assume we're here for the scoped predicate "SELECT[4].i = SELECT[1].j". Then we want to remap the scoped operand, "SELECT[1].j", so that it will point to the correct column in "SELECT[3]". We do NOT, however, want to remap the non-scoped operand "SELECT[4].i" because that operand is already pointing to the correct result set--namely, to a column in SELECT[4]. That non-scoped operand should not change regardless of how far down the UNION subtree the scoped predicate is pushed. If we did try to remap the non-scoped operand, it would end up pointing to result sets too low in the tree, which could lead to execution-time errors. So when we remap a scoped predicate, we have to make sure we only remap the scoped operand. That's what this method does.

Returns:boolean

True if this predicate is a scoped predicate, in which case we performed a one-sided remap. False if the predicate is not scoped; the caller can then make the calls to perform a "normal" remap on this predicate.