Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jelNg-0006g5-R3 for pgsql-hackers@arkaria.postgresql.org; Fri, 29 May 2020 20:13:29 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1jelN8-0004JT-NC for pgsql-hackers@arkaria.postgresql.org; Fri, 29 May 2020 20:12:54 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jelN8-0004JM-BO for pgsql-hackers@lists.postgresql.org; Fri, 29 May 2020 20:12:54 +0000 Received: from mail-pf1-x432.google.com ([2607:f8b0:4864:20::432]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1jelN0-0001Tz-3F for pgsql-hackers@postgresql.org; Fri, 29 May 2020 20:12:53 +0000 Received: by mail-pf1-x432.google.com with SMTP id f3so369024pfd.11 for ; Fri, 29 May 2020 13:12:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=j-davis-com.20150623.gappssmtp.com; s=20150623; h=message-id:subject:from:to:cc:date:in-reply-to:references :mime-version:content-transfer-encoding; bh=E9Yy7vdgkS1MO7OIysMYgxKB8QmWGEAwCbYr+d2Z2BA=; b=f89TsyowyipKuKWmp8gpC3bgSvz8OfQvQu54Z4L9oqOJKd+ytSF0r1azb0mBvkHwXD xEzjFo8BAPClUPXMf+lYd9owc/oR/mn6es9+Qf9XkoGX/E869K7VIyjzdOU6TMsk3u0F rPjRXtetiFzPkDxKH9dboj5s6Y2Vv9EacMHn6sjcyC0c7tnwWviik3iU09vrfKGugStg Q65pUxEAMHg+9NbayLzmRLm9vtoPjV0532t2O7+ESB4q/ZWBfZlCvfmZOcdcm+CUi4HY wCihM2XZQE08w3bH4T/cUnXreoxAkfm/fofTGsOAi2M6xRUlSm9ZYgg7Gin4CusC5svP Iyvw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:message-id:subject:from:to:cc:date:in-reply-to :references:mime-version:content-transfer-encoding; bh=E9Yy7vdgkS1MO7OIysMYgxKB8QmWGEAwCbYr+d2Z2BA=; b=Vcss6Qz4KjFwBExEQpDCVQJC+KqYpdPp1ztuUmQVJ9q3n44prpdDktvED0WY6z62k0 3SGEF/4BxmyV2MKORky0gO/a6FKAqE39Oh/ntxd8mNGSulcQZuHjF5Z+YdacpjmWwOqh rl5b4UdIIYTtq+xgSAtD5P+6Bmb1GlFlfzAYnDVO/4Ga2Yj/A144ZwYUot5Ft6Cip/h+ NBsIjEPiFrE+f2etqTBtt4NiCqsq+K6lWPqM2qnMdrglgdF/UX76V23tUxuBP/YrlbOI RA+612lue+SvJRdPifiy1Q+cCTAXA1fYAI9v8cgkT26QDZSwTMTC1buwdrxJh7Tt9Q82 XXLg== X-Gm-Message-State: AOAM533U3ZysR9TzVES+xmKvodYBh02WLV0G+NzId8oT/HREfi1rP1/E hMMF6DGBrRHXZYtc0w2oBbmFTQ== X-Google-Smtp-Source: ABdhPJwKyRkD9nSAJ5upLmXiExNCRf5jDB3dSyeAVGZYcfZE5HidVNVWCVMOa/IT5mq814XesRZ08Q== X-Received: by 2002:a63:3c18:: with SMTP id j24mr9645938pga.256.1590783163790; Fri, 29 May 2020 13:12:43 -0700 (PDT) Received: from jdavis.lan (c-73-231-146-4.hsd1.ca.comcast.net. [73.231.146.4]) by smtp.gmail.com with ESMTPSA id m2sm7876413pfe.41.2020.05.29.13.12.41 (version=TLS1_2 cipher=ECDHE-ECDSA-CHACHA20-POLY1305 bits=256/256); Fri, 29 May 2020 13:12:42 -0700 (PDT) Message-ID: <312bf7eb53b0b9f953e4eb0c704ed4f2121bce4d.camel@j-davis.com> Subject: Re: Trouble with hashagg spill I/O pattern and costing From: Jeff Davis To: Tomas Vondra Cc: Melanie Plageman , Thomas Munro , pgsql-hackers , HeikkiLinnakangas Date: Fri, 29 May 2020 13:12:40 -0700 In-Reply-To: <20200529130454.el6qyuukj3ofs4eu@development> References: <20200525225909.aifxjm53hw4xyzxd@development> <20200526141524.ohtvrp23vxosgivl@development> <20200526191511.d7pwz4awrvdm4p6j@development> <0589f869969de2f3e9713689159c7c4fbe1fcfa5.camel@j-davis.com> <20200527090704.onkjogxeg34ib5cn@development> <20200528185750.aamptuqdzrggqi5c@development> <0fb3456095d469cc20a9ee7e76edfe9237dae24f.camel@j-davis.com> <20200529130454.el6qyuukj3ofs4eu@development> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.28.5-0ubuntu0.18.04.2 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk On Fri, 2020-05-29 at 15:04 +0200, Tomas Vondra wrote: > Ah, right. Yeah, we only need to check for AGG_HASH here. Moreover, > AGG_MIXED probably does not need the tlist tweak, because the input > should be pre-sorted as with AGG_SORTED. > > And we should probably do similar check in the > create_groupinsets_path, > I guess. At first I thought we can't do that before inspecting > rollups, > which only happens later in the function, but now I see there's > aggstrategy in GroupingSetsPath too. Looks good. Jeff