Return-Path: X-Original-To: archive-asf-public-internal@cust-asf2.ponee.io Delivered-To: archive-asf-public-internal@cust-asf2.ponee.io Received: from cust-asf.ponee.io (cust-asf.ponee.io [163.172.22.183]) by cust-asf2.ponee.io (Postfix) with ESMTP id 10750200AC8 for ; Tue, 24 May 2016 05:01:50 +0200 (CEST) Received: by cust-asf.ponee.io (Postfix) id 0F226160A24; Tue, 24 May 2016 03:01:50 +0000 (UTC) Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by cust-asf.ponee.io (Postfix) with SMTP id 5758A160A0E for ; Tue, 24 May 2016 05:01:49 +0200 (CEST) Received: (qmail 63214 invoked by uid 500); 24 May 2016 03:01:48 -0000 Mailing-List: contact dev-help@impala.incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@impala.incubator.apache.org Delivered-To: mailing list dev@impala.incubator.apache.org Received: (qmail 63203 invoked by uid 99); 24 May 2016 03:01:47 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd4-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 24 May 2016 03:01:47 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd4-us-west.apache.org (ASF Mail Server at spamd4-us-west.apache.org) with ESMTP id D953AC0713 for ; Tue, 24 May 2016 03:01:46 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd4-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 0.362 X-Spam-Level: X-Spam-Status: No, score=0.362 tagged_above=-999 required=6.31 tests=[RDNS_DYNAMIC=0.363, SPF_PASS=-0.001] autolearn=disabled Received: from mx1-lw-us.apache.org ([10.40.0.8]) by localhost (spamd4-us-west.apache.org [10.40.0.11]) (amavisd-new, port 10024) with ESMTP id WPuodU1k3QQO for ; Tue, 24 May 2016 03:01:44 +0000 (UTC) Received: from ip-10-146-233-104.ec2.internal (ec2-75-101-130-251.compute-1.amazonaws.com [75.101.130.251]) by mx1-lw-us.apache.org (ASF Mail Server at mx1-lw-us.apache.org) with ESMTPS id 9EF735F244 for ; Tue, 24 May 2016 03:01:44 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by ip-10-146-233-104.ec2.internal (8.14.4/8.14.4) with ESMTP id u4O31hFe002767; Tue, 24 May 2016 03:01:43 GMT Message-Id: <201605240301.u4O31hFe002767@ip-10-146-233-104.ec2.internal> Date: Tue, 24 May 2016 03:01:43 +0000 From: "Taras Bobrovytsky (Code Review)" To: impala-cr@cloudera.com, dev@impala.incubator.apache.org CC: Dan Hecht Reply-To: tbobrovytsky@cloudera.com X-Gerrit-MessageType: comment Subject: =?UTF-8?Q?[Impala-CR](cdh5-2.6.0=5F5.8.0)_IMPALA-3163:_Fix_Decimal_to_Timestamp_casting=0A?= X-Gerrit-Change-Id: Iabeea9f4ab4880b2f814408add63c77916e2dba9 X-Gerrit-ChangeURL: X-Gerrit-Commit: 12fc7544b799f1f85bba17adb49f3fd131c58cd2 In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Content-Disposition: inline User-Agent: Gerrit/2.10-rc0 archived-at: Tue, 24 May 2016 03:01:50 -0000 Taras Bobrovytsky has posted comments on this change. Change subject: IMPALA-3163: Fix Decimal to Timestamp casting ...................................................................... Patch Set 2: (6 comments) http://gerrit.cloudera.org:8080/#/c/3154/2/be/src/exprs/decimal-operators-ir.cc File be/src/exprs/decimal-operators-ir.cc: Line 569: int64_t > should these be int32_t in this case? if not, why? Yeah, it makes sense that they can be int32_t. The entire Decimal4Value is can fit into int32_t. Line 571: LIKELY > why is this LIKELY? I think it's going to be very rare that someone has a decimal with scale larger than 9 that they want to convert to timestamp. In other words, why would someone have a decimal column that represents timestamp with scale greater than 9 (for example picosecond precision)? Line 577: } > How about factoring this block into a (templated) subroutine? Done http://gerrit.cloudera.org:8080/#/c/3154/2/be/src/exprs/expr-test.cc File be/src/exprs/expr-test.cc: Line 1360: 260000000000 > what i'm asking is whether the upper limit changes between the old and new I did some investigating, but it seems it's very close, but not exactly the same. The larger the precision and scale, the bigger the difference is. I'll investigate some more tomorrow. Line 3766: We get some decimal-binary skew here > isn't this no longer the case? Done Line 3799: // We get some decimal-binary skew here > same Done -- To view, visit http://gerrit.cloudera.org:8080/3154 To unsubscribe, visit http://gerrit.cloudera.org:8080/settings Gerrit-MessageType: comment Gerrit-Change-Id: Iabeea9f4ab4880b2f814408add63c77916e2dba9 Gerrit-PatchSet: 2 Gerrit-Project: Impala Gerrit-Branch: cdh5-2.6.0_5.8.0 Gerrit-Owner: Taras Bobrovytsky Gerrit-Reviewer: Dan Hecht Gerrit-Reviewer: Taras Bobrovytsky Gerrit-HasComments: Yes