Return-Path: X-Original-To: apmail-drill-dev-archive@www.apache.org Delivered-To: apmail-drill-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id E905C186D7 for ; Tue, 25 Aug 2015 15:03:15 +0000 (UTC) Received: (qmail 87567 invoked by uid 500); 25 Aug 2015 15:03:11 -0000 Delivered-To: apmail-drill-dev-archive@drill.apache.org Received: (qmail 87469 invoked by uid 500); 25 Aug 2015 15:03:11 -0000 Mailing-List: contact dev-help@drill.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@drill.apache.org Delivered-To: mailing list dev@drill.apache.org Received: (qmail 86972 invoked by uid 99); 25 Aug 2015 15:03:11 -0000 Received: from Unknown (HELO spamd1-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 25 Aug 2015 15:03:11 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd1-us-west.apache.org (ASF Mail Server at spamd1-us-west.apache.org) with ESMTP id E8A96EDC4C for ; Tue, 25 Aug 2015 15:03:10 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd1-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 2.921 X-Spam-Level: ** X-Spam-Status: No, score=2.921 tagged_above=-999 required=6.31 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=3, T_KAM_HTML_FONT_INVALID=0.01, T_REMOTE_IMAGE=0.01, URIBL_BLOCKED=0.001] autolearn=disabled Authentication-Results: spamd1-us-west.apache.org (amavisd-new); dkim=pass (1024-bit key) header.d=maprtech.com Received: from mx1-us-east.apache.org ([10.40.0.8]) by localhost (spamd1-us-west.apache.org [10.40.0.7]) (amavisd-new, port 10024) with ESMTP id wLrPeXMqeGHp for ; Tue, 25 Aug 2015 15:02:58 +0000 (UTC) Received: from mail-yk0-f171.google.com (mail-yk0-f171.google.com [209.85.160.171]) by mx1-us-east.apache.org (ASF Mail Server at mx1-us-east.apache.org) with ESMTPS id 73E6042B2E for ; Tue, 25 Aug 2015 15:02:58 +0000 (UTC) Received: by ykdt205 with SMTP id t205so159816907ykd.1 for ; Tue, 25 Aug 2015 08:02:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=maprtech.com; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=WSbG2Qb4sMSXkwRuJS8FYHGGPSF9luxjKW3jS7mgpDQ=; b=RgfH3GhkNcs7nu0KiVhz80bOlXxsmfkp+Qlx5BaniGrse1mSLvJynwkFSbKn9Ycg3f MNcCuDyvLOn/VOtkn3Rl570+fVyFoXZ6OPNic4Xv7n0WVTRe4Apjrjsz36ZL1Z0sfUp1 QyqiZwS+Dfx51z3oWXiS2HNtmt4pRWv59L0j8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=WSbG2Qb4sMSXkwRuJS8FYHGGPSF9luxjKW3jS7mgpDQ=; b=Za66t4dphpcCfY4lghgdrXNRib4X1ZjjYFlew+1ho0//83e07o4Le3X1bybmFSZNVO /8fHN+8rlhP1Mh4mAK8TMphPH4GKoD4fYllQSBpaYrzJTt4+dw61NwJSbZOTMLaaLNN1 lAg48xjIc+WaN+It4xJNHa8Socmpp4dqpX//W2GwLk4FYTqJKMVZthTtM4GXGC9x2kgC eyGShdB5Vg0vPV6sAnfaM8PJls81+qWGZcdomqf5yoNaNuzIDhYmgUNX1P+iCd9yE9TE RDUpTg3nadBR2GYj5qMtGxK9/1jABOObdY86OiTY2Bs1oI1caAuSb5Oz8C9R0Lbcn7YJ b75A== X-Gm-Message-State: ALoCoQkVGfSfSFcdzuJtBAJpcgz8dxp8p/8R3f8T670LiDEZSJG5/lwgRm0L1onE6WjI9KxJoaRw MIME-Version: 1.0 X-Received: by 10.129.49.200 with SMTP id x191mr37555822ywx.56.1440514978079; Tue, 25 Aug 2015 08:02:58 -0700 (PDT) Received: by 10.13.226.214 with HTTP; Tue, 25 Aug 2015 08:02:58 -0700 (PDT) In-Reply-To: References: Date: Tue, 25 Aug 2015 08:02:58 -0700 Message-ID: Subject: Re: zeroVectors() interface for value vectors From: Abdel Hakim Deneche To: "dev@drill.apache.org" Content-Type: multipart/alternative; boundary=001a1142196e90193c051e2407a0 --001a1142196e90193c051e2407a0 Content-Type: text/plain; charset=UTF-8 Another important point to keep in mind here: ValueVectorWriteExpression operates under the "undocumented" assumption that the destination vector is empty, this way it can safely skip writing null values. In the case of window functions I am using a value vector as an internal buffer to hold values between batches which voids the assumption. If this assumption is indeed correct then adding zeroVector to value vectors is indeed the way to go. On Mon, Aug 24, 2015 at 8:30 PM, Jacques Nadeau wrote: > In general, let's try to avoid extending the core structures like value > vector read and write expressions for a single operator. Zerovector is > trivial to implement so let's resolve that way (trivial since the > underlying vector already has it and we just need to delegate down). > On Aug 24, 2015 3:36 PM, "Aman Sinha" wrote: > > > I am reviewing Hakim's patch for DRILL-3668 (first_value window function > > incorrect result). His code uses ValueVectorWriteExpression to set > values > > in an internal batch which get re-used across different partitions of the > > window function. Ideally, we just want to zero out the vector rather > than > > calling clear() since clear() will release the buffer. > > > > However, currently zeroVectors() is only supported by FixedWidthVector, > not > > VariableWidthVector. * Should there be such an interface for variable > > width ? * The implementation could zero out just the offset vector. > > > > In the absence of such an interface, Hakim has added a boolean flag > > witeNulls to ValueVectorWriteExpression (see > > > > > https://github.com/adeneche/incubator-drill/commit/cab73cd1a50163dd25fe0f9c55c264780ea3616d > > ) > > and is conditionally doing the null-ing out in the generated code. It > > won't affect the normal code path, it would get used for specific window > > functions. > > > > I am thinking of committing his patch and tracking the zeroVectors() > > enhancement separately (if people agree that it would be useful). Let me > > know... > > > > Aman > > > -- Abdelhakim Deneche Software Engineer Now Available - Free Hadoop On-Demand Training --001a1142196e90193c051e2407a0--