Github user sureshsubbiah commented on a diff in the pull request:
https://github.com/apache/incubator-trafodion/pull/174#discussion_r45081166
--- Diff: core/sql/optimizer/OptPhysRelExpr.cpp ---
@@ -3910,6 +3910,20 @@ InputPhysicalProperty* NestedJoin::generateIpp(
InputPhysicalProperty* ipp = NULL;
// ----------------------------------------------------------------
+ // If there is a cardinality constraint on the outer child, we'll
+ // pass that information along to the inner child.
+ // ----------------------------------------------------------------
+ Cardinality minRows;
+ Cardinality maxRows;
+ CardConstraint * outerCardinalityConstraint = NULL;
+
+ if (getGroupAttr()->hasCardConstraint(minRows, maxRows))
--- End diff --
Maybe in the case described in TRAFODION-1585 the CardConstraint on the
outer child, resulted in a CardConstraint being synthesized for the Join too?
(since the Join is on key columns?), hence this change produced the desired
plan.
That raises the question on whether the CardConstraint that is sent down to
the inner child states that
a) The number of probes or unique values for input from outer is limited by
the CradConstraint
or b) whether the output of the inner child satisfies the CardConstraint.
This is a basic question, but my knowledge of how Ipp works is limited.
Also do we need to consider inputs or probes that could come from the top.
I am thinking that the right child of an NJ can see several requests, even
though the left child send only one probe for each request that it receives.
All the questions I have are minor and for my personal knowledge, I think
the change is good.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at [email protected] or file a JIRA ticket
with INFRA.
---
