[
https://issues.apache.org/jira/browse/TRAFODION-1581?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15049422#comment-15049422
]
ASF GitHub Bot commented on TRAFODION-1581:
-------------------------------------------
Github user DaveBirdsall commented on a diff in the pull request:
https://github.com/apache/incubator-trafodion/pull/218#discussion_r47156394
--- Diff: core/sql/optimizer/GroupAttr.cpp ---
@@ -580,6 +612,127 @@ void
GroupAttributes::addSuitableCompRefOptConstraints(
} // loop over constraints
}
+// a const method for validating eliminated columns in a sort order,
+// usually called for validating an earlier result created with
+// the next method below, tryToEliminateOrderColumnBasedOnEqualsPred()
+NABoolean GroupAttributes::canEliminateOrderColumnBasedOnEqualsPred(
+ ValueId col) const
+{
+ // cast away const-ness and call the non-const method without
+ // predicates, which will mean it won't side-effect "this"
+ return const_cast<GroupAttributes *>(this)->
+ tryToEliminateOrderColumnBasedOnEqualsPred(col, NULL);
+}
+
+// This and the previous method are used to match required sort orders
+// or arrangements to an actual key ordering of a table, in cases
+// where some columns are equated to a constant, like this, with the
+// clustering key being (a,b,c)
+//
+// select ...
+// from t
+// where a = 5
+// order by b
+//
+// Note that for VEGs, this is handled differently (see
+// ValueIdList::satisfiesReqdOrder), this code is only for non-VEG
+// cases (usually computed columns, also varchar).
+//
+// If we eliminate a column based on a supplied predicate, then
+// this predicate is added as an Optimizer check constraint to the
+// group attributes, so that future calls will continue to accept
+// the simplified sort order.
+NABoolean GroupAttributes::tryToEliminateOrderColumnBasedOnEqualsPred(
+ ValueId col,
+ const ValueIdSet *preds)
+{
+ NABoolean result = FALSE;
+
+ if (preds || hasConstraintOfType(ITM_CHECK_OPT_CONSTRAINT))
+ {
+ // Comparison failed. If the caller provided predicates,
+ // then we can try something similar to what we did with
+ // group attributes above. If the predicate equate the
+ // column with a constant, then we can eliminate it as
+ // well. Note that we don't expect the requirements to
+ // omit such columns, since the parent will usually not
+ // know about such predicates, so we check this condition
+ // only after trying the regular method.
+ //
+ // This situation typically happens with computed columns
+ // where predicates are added after VEGs are formed
+
+ ValueIdSet checkConstraints;
+ ValueIdSet checkPreds;
+
+ // look for predicates we remembered from earlier calls
+ getConstraintsOfType(ITM_CHECK_OPT_CONSTRAINT,
+ checkConstraints);
+
+ for (ValueId c = checkConstraints.init();
+ checkConstraints.next(c);
+ checkConstraints.advance(c))
+ checkPreds += static_cast<CheckOptConstraint *>(
+ c.getItemExpr())->getCheckPreds();
+
+ // also use newly provided predicates
+ if (preds)
+ checkPreds += *preds;
+
+ // if the column is descending, then get rid of the Inverse
+ // operator for the next check
+ if (col.getItemExpr()->getOperatorType() == ITM_INVERSE)
+ col = col.getItemExpr()->child(0).getValueId();
+
+ // convert col from a VEGRef to a base column, if needed,
+ // the ScanKey method below wants a real column as input
+ if (col.getItemExpr()->getOperatorType() == ITM_VEG_REFERENCE)
+ {
+ const ValueIdSet &vegMembers =
+ static_cast<VEGReference *>(col.getItemExpr())->
+ getVEG()->getAllValues();
+ for (ValueId b=vegMembers.init();
+ vegMembers.next(b);
+ vegMembers.advance(b))
+ if (b.getItemExpr()->getOperatorType() == ITM_BASECOLUMN)
+ col = b;
--- End diff --
So, you'll get the last ITM_BASECOLUMN in the ValueIdSet vegMembers. I
gather that any base column will do? Or must it be from a specific table? (I'm
wondering about a join predicate.)
> Add a TMUDF that can return a JDBC result set as table-valued output
> --------------------------------------------------------------------
>
> Key: TRAFODION-1581
> URL: https://issues.apache.org/jira/browse/TRAFODION-1581
> Project: Apache Trafodion
> Issue Type: Sub-task
> Components: sql-general
> Affects Versions: 1.3-incubating
> Reporter: Hans Zeller
> Assignee: Hans Zeller
> Fix For: 2.0-incubating
>
>
> One way to read data from other data sources would be a Trafodion TMUDF that
> takes a connection string, an SQL statement and other necessary info as an
> input, connects to a JDBC data source, prepares the statement, and returns
> the result set as a table-valued output. This would enable a basic connector
> for many data sources, including Spark, Drill and Kafka.
> Specifically, I would like to add a "predefined" TMUDF to Trafodion that
> takes the following parameters:
> 1. The name of a jar with a JDBC driver.
> 2. A connection string to use
> 3. The class name of the driver
> 4. A user id
> 5. A password
> 6. The type of processing to do (right now only one type is supported)
> 7. Info depending on the type.
> The first type of processing I would like to add is "source", and it does the
> following: It accepts a list of SQL statements to execute. Only one of these
> statements can return a result set. The data in the result set will be
> returned as table-valued output.
> Future processing types could do a parallel select like ODB does or they
> could insert into a table on the system identified by the JDBC driver info.
> All parameters need to be compile-time constants, so that the UDF can connect
> to the data source at compile time and prepare the statement. Based on the
> prepared statement, it will determine number, names and SQL types of the
> column(s) of the table-valued result.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
