[
https://issues.apache.org/jira/browse/DRILL-5419?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15988000#comment-15988000
]
ASF GitHub Bot commented on DRILL-5419:
---------------------------------------
Github user paul-rogers commented on a diff in the pull request:
https://github.com/apache/drill/pull/819#discussion_r113833863
--- Diff: common/src/main/java/org/apache/drill/common/types/Types.java ---
@@ -636,43 +658,63 @@ public static String toString(final MajorType type) {
/**
* Get the <code>precision</code> of given type.
- * @param majorType
- * @return
+ *
+ * @param majorType major type
+ * @return precision value
*/
public static int getPrecision(MajorType majorType) {
- MinorType type = majorType.getMinorType();
-
- if (type == MinorType.VARBINARY || type == MinorType.VARCHAR) {
- return 65536;
- }
-
if (majorType.hasPrecision()) {
return majorType.getPrecision();
}
- return 0;
+ return isScalarStringType(majorType) ? MAX_VARCHAR_LENGTH : UNDEFINED;
--- End diff --
My point is that calculating things based on metadata only works in systems
that define metadata. Drill does not. In the vast majority of the cases, the
length of a string column is unknown: there is no system catalog to tell us the
expected (or maximum) length. We can guess as you suggest, but that only helps
in the few cases where someone uses constants or functions. It does not help:
SELECT myStringCol FROM myTable
The only reliable way to estimate the column width is to sample data. But,
of course, doing that is complex: we can't sample at the output (Screen), else
we'd have to run, say, an entire sort. So, we have to sample at the *input*: in
the scanner.
In particular, we need each scanner to:
1. Read one batch of data.
2. Use that data to build the schema (as we already do.)
3. Use that data to estimate maximum string column width.
4. Send the schema (only) downstream as part of the fast path.
5. On the second call to next(), return the cached record batch.
6. On the third call to next(), read a new record batch.
An open question is this: if the first batch sees only strings of 10
characters, say, but the second batch sees strings of 100 characters, is this a
schema change?
> Calculate return string length for literals & some string functions
> -------------------------------------------------------------------
>
> Key: DRILL-5419
> URL: https://issues.apache.org/jira/browse/DRILL-5419
> Project: Apache Drill
> Issue Type: Bug
> Affects Versions: 1.9.0
> Reporter: Arina Ielchiieva
> Assignee: Arina Ielchiieva
> Attachments: version_with_cast.JPG
>
>
> Though Drill is schema-less and cannot determine in advance what the length
> of the column should be but if query has an explicit type/length specified,
> Drill should return correct column length.
> For example, JDBC / ODBC Driver is ALWAYS returning 64K as the length of a
> varchar or char even if casts are applied.
> Changes:
> *LITERALS*
> String literals length is the same as actual literal length.
> Example: for 'aaa' return length is 3.
> *CAST*
> Return length is the one indicated in cast expression. This also applies when
> user has created view where each string columns was casted to varchar with
> some specific length.
> This length will be returned to the user without need to apply cast one more
> time. Below mentioned functions can take leverage of underlying varchar
> length and calculate return length.
> *LOWER, UPPER, INITCAP, REVERSE, FIRST_VALUE, LAST_VALUE*
> Return length is underlying column length, i.e. if column is known, the same
> length will be returned.
> Example:
> lower(cast(col as varchar(30))) will return 30.
> lower(col) will return max varchar length, since we don't know actual column
> length.
> *LAG, LEAD*
> Return length is underlying column length but column type will be nullable.
> *LPAD, RPAD*
> Pads the string to the length specified. Return length is this specified
> length.
> *CONCAT, CONCAT OPERATOR (||)*
> Return length is sum of underlying columns length. If length is greater then
> varchar max length, varchar max length is returned.
> *SUBSTR, SUBSTRING, LEFT, RIGHT*
> Calculates return length according to each function substring rules, for
> example, taking into account how many char should be substracted.
> *IF EXPRESSIONS (CASE STATEMENT, COALESCE), UNION OPERATOR*
> When combining string columns with different length, return length is max
> from source columns.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
