Return-Path: X-Original-To: apmail-spark-user-archive@minotaur.apache.org Delivered-To: apmail-spark-user-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id E3ADE18C63 for ; Thu, 8 Oct 2015 10:17:39 +0000 (UTC) Received: (qmail 54624 invoked by uid 500); 8 Oct 2015 10:17:35 -0000 Delivered-To: apmail-spark-user-archive@spark.apache.org Received: (qmail 54523 invoked by uid 500); 8 Oct 2015 10:17:35 -0000 Mailing-List: contact user-help@spark.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Delivered-To: mailing list user@spark.apache.org Received: (qmail 54512 invoked by uid 99); 8 Oct 2015 10:17:35 -0000 Received: from Unknown (HELO spamd1-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 08 Oct 2015 10:17:35 +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 530C2C4A6F for ; Thu, 8 Oct 2015 10:17:35 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd1-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 2.9 X-Spam-Level: ** X-Spam-Status: No, score=2.9 tagged_above=-999 required=6.31 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=disabled Authentication-Results: spamd1-us-west.apache.org (amavisd-new); dkim=pass (1024-bit key) header.d=typesafe.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 ykzTyevrWzwn for ; Thu, 8 Oct 2015 10:17:26 +0000 (UTC) Received: from mail-vk0-f43.google.com (mail-vk0-f43.google.com [209.85.213.43]) by mx1-us-east.apache.org (ASF Mail Server at mx1-us-east.apache.org) with ESMTPS id 3B037439BA for ; Thu, 8 Oct 2015 10:17:26 +0000 (UTC) Received: by vkat63 with SMTP id t63so28743100vka.1 for ; Thu, 08 Oct 2015 03:17:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=typesafe.com; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=nz7NFo6Qc7md0Gks/F9+yXbICXufpbSI2X/XC6sqSXA=; b=dcG6TO5P5KWGjxVcmcMBQzUEMXvc4RD6COmoculNO5CQNnpsamFQxTnmL8H4+9VKo4 /xT8fYdxIVXbHynwz3y/DZp+QwxT7w8RoEX9d2lRFsKzlqDVm7DYOV480iSJgE+HF88/ ckLDkxJhq5xS/dZYi+2zupddJM99ebzr80pxQ= 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:from:date :message-id:subject:to:cc:content-type; bh=nz7NFo6Qc7md0Gks/F9+yXbICXufpbSI2X/XC6sqSXA=; b=OWUXOCjzBdU/r+qwrp9owX82ouVrQkmdTARI/bZKih1MKuA45ZGFh6G96o1IBjfiZZ u1hLB+hwYn8eoUJ2N80gjl+ABZmyOc/+AdUHHIdpvhm8mEcEbD78LGHG+1jj27siEdVw p26B4OJdLLhJ1SBUKoVM0/tcGW2e/S9WG2i0SBJXYvWWRHyb9KDMJrOuDyxjbsVZPalP bfMijRNC4sBWGb/Ip6YxWUO/XICwjhCULP40BhWroEaFWYmHkHgjaShzN3N9T6oDcOXr /uGgRjbIIKbFYO6j9kczvFLGnY8jdisZPD9favLyF7On99P1FuLyuBtklVkwYOoIQ6e9 iLgw== X-Gm-Message-State: ALoCoQnIkwc6jfAVXipFyQkOdCZWjCTCGwBHt+MIWYO20pSck2zj9EkhD2V9uj5ASi0FS9leRNuE X-Received: by 10.31.185.12 with SMTP id j12mr4064427vkf.98.1444299445874; Thu, 08 Oct 2015 03:17:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.7.81 with HTTP; Thu, 8 Oct 2015 03:17:06 -0700 (PDT) In-Reply-To: References: From: =?UTF-8?Q?Iulian_Drago=C8=99?= Date: Thu, 8 Oct 2015 12:17:06 +0200 Message-ID: Subject: Re: Is coalesce smart while merging partitions? To: Cesar Flores Cc: user Content-Type: multipart/alternative; boundary=001a1143a66a6bc8950521952b0c --001a1143a66a6bc8950521952b0c Content-Type: text/plain; charset=UTF-8 It's smart. Have a look at https://github.com/apache/spark/blob/master/core/src/main/scala/org/apache/spark/rdd/CoalescedRDD.scala#L123 On Thu, Oct 8, 2015 at 4:00 AM, Cesar Flores wrote: > It is my understanding that the default behavior of coalesce function when > the user reduce the number of partitions is to only merge them without > executing shuffle. > > My question is: Is this merging smart? For example does spark try to merge > the small partitions first or the election of partitions to merge is random? > > > Thanks > -- > Cesar Flores > -- -- Iulian Dragos ------ Reactive Apps on the JVM www.typesafe.com --001a1143a66a6bc8950521952b0c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
It's smart. Have a look at=C2=A0https://github.com/apache/spark/blob/master/core/sr= c/main/scala/org/apache/spark/rdd/CoalescedRDD.scala#L123

On Thu, Oct 8, 2015 at 4:00= AM, Cesar Flores <cesar7@gmail.com> wrote:
It is my understanding that the default behavior of coa= lesce function when the user reduce the number of partitions is to only mer= ge them without executing shuffle.

My question is: Is th= is merging smart? For example does spark try to merge the small partitions = first or the election of partitions to merge is random?


Thanks
--
Cesar Flores



--

--
Iulian Dragos

<= /div>
------
Reactive Apps on the JVM
www.typesafe.com

--001a1143a66a6bc8950521952b0c--