drill-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From paul-rogers <...@git.apache.org>
Subject [GitHub] drill issue #517: DRILL-4704 fix
Date Fri, 05 Aug 2016 00:30:23 GMT
Github user paul-rogers commented on the issue:

    https://github.com/apache/drill/pull/517
  
    The proximate cause of this particular issue is the mechanism by which the cast function
is being generated. As others have noted, the code is passing through lines 316-316. My guess
is that the materializer is working out how to call this function:
    
    Decimal28SparseFunctions.Decimal28SparseEqual( Decimal28Sparse left, Decimal28Sparse right
)
    The materializer sees: D28SEqual( Decimal28Sparse, Integer )
    
    The code wants to convert the Integer to a Decimal28Sparse. It asks the argument for its
precision and scale. But, since the argument just specifies the "minor type" (SQL type), it
does not have the extended attributes of precision and scale. Thus, the annotations in the
function definition are the ultimate cause of the precision being 0:
    
    @Param Decimal28SparseHolder left;
    @Param Decimal28SparseHolder right;
    
    Now, we might argue that the code should be using, as the target (p, s) the (p,s) of the
left argument (the one that is already a decimal). But, the materializer does not know that
this is an operator; it treats all functions the same (operators and otherwise.) So, the materializer
does not know that we should treat arguments in this way. All it knows is that it has an Integer
and wants a D28S (of, presumably, any p & s).
    
    Next, we can ask how DS28Equal handles the (p,s) of the two arguments: must they be the
same or can they be different? Looking at the code (as best as I can tell), the code will
align values with different (p,s) values. Thus, say, values of Decimal28( 10, 2 ) and Decimal28(
8, 0 ) will compare properly.
    
    So, back to the cast from Integer to D28S. As Dave suggests, we can interpret (precision
== 0) to mean "you figure it out": we can set (p,s) way we want.
    
    Dave's fix computes the precision based on the actual integer value. But, since the comparison
can handle any valid (p,s), we might as well set them to a constant. Since the maximum Integer
value is 2 billion, we can just use a constant (10,0).
    
    If the selected precision is constant, then the cost is low and the solution is fine for
both for constant integers (as in the original case), and for per-row conversions (as in Aman's
concern.)


---
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 infrastructure@apache.org or file a JIRA ticket
with INFRA.
---

Mime
View raw message