Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.92) (envelope-from ) id 1jCUxm-0004Ay-Pf for pgsql-hackers@arkaria.postgresql.org; Thu, 12 Mar 2020 21:01:54 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1jCUxl-00087E-MN for pgsql-hackers@arkaria.postgresql.org; Thu, 12 Mar 2020 21:01:53 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1jCUxl-00086U-AO for pgsql-hackers@lists.postgresql.org; Thu, 12 Mar 2020 21:01:53 +0000 Received: from mail-qk1-x742.google.com ([2607:f8b0:4864:20::742]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1jCUxi-0001i7-7d for pgsql-hackers@postgresql.org; Thu, 12 Mar 2020 21:01:52 +0000 Received: by mail-qk1-x742.google.com with SMTP id z25so3899493qkj.4 for ; Thu, 12 Mar 2020 14:01:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telsasoft-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=IMu7k0UR+V9iohn8l/8TBk6xCoSQoTlpnsgRikAVm1M=; b=SQvkWjRiowN9w1hrzC2uYRZCNDep36N2K+bctg9Gc8JNz6rkPjVdJkUTODKfRnf26Q omksGib/iVUdgJez7vEEHrmOmYc3XhQfQRMVgGH3aJEV59cfCgqe6VxAqJoOhZLGr5Md k9++CGep/yXBnecgI7K3Md2WifEkDrokMLYAVgHXmeWERUfttJsa1vUOfjw7Q9AGTXKT 4cGBwkmcXpQ2uU40yK7KqkqIc6cb7nfHXfgDUYgYVGOfRvPOmo/oXwpcYdm70Y+wvmDC e67UBbA2Wgh4Y5bheKTq1Az5MQRa05i/wrMJNFPQdpEErBBVqLX4eOyXmwfgKyjD4bPZ j5mg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=IMu7k0UR+V9iohn8l/8TBk6xCoSQoTlpnsgRikAVm1M=; b=tHQ+kUjahtMdC3p8JC7kl8YPfOv76TUiXGxO9mXp3qEG02Z3l7OfyZOLSQi/kWE8vj rVGn8P5pEmCuGaxqX9GXsFR8v3E9yIaJwyBP87C8re4y7AkiEl3eCno6WEeNw8zhbDIe t7sXXLVfTjofMteH9ibPIamPSEyDLrxV1+SWTcvycdB3Fz9e0lFK8pGHRhYkkxuaz7nD q3FLVu6SmmpC8Bwz/4ZxcttAxKdlv2uKrz0jtP6aNxxS1tmV1BZN7/c8ZPEEYDZL+8MJ PAdqWe7/xOrJC1b0hgVKuLea9/sNx5OfA45sXq6J8qWd+qBbXMKm2lDBwC8hU6hmY6Ns 5l7Q== X-Gm-Message-State: ANhLgQ2r1cI3BVFoMDTlBGRfxXlalitoSPxjTxFDIwmFPbzg6bYzRgnS cWgNFSnjUWRGHT+LDH3vJh5hmA== X-Google-Smtp-Source: ADFU+vtkaPif1kpRThN3Vh//ZbgqPx5aAUJ2AnSMHKO0kErEb1c7qgjPpovGzzsdDWp0HcYK3JlyqA== X-Received: by 2002:a05:620a:1325:: with SMTP id p5mr9455660qkj.439.1584046909212; Thu, 12 Mar 2020 14:01:49 -0700 (PDT) Received: from pryzbyj (charmander.telsasoft.com. [50.244.222.1]) by smtp.gmail.com with ESMTPSA id v1sm4786065qtc.30.2020.03.12.14.01.47 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 12 Mar 2020 14:01:48 -0700 (PDT) Received: by pryzbyj (Postfix, from userid 1000) id 83907800719; Thu, 12 Mar 2020 16:01:46 -0500 (CDT) Date: Thu, 12 Mar 2020 16:01:46 -0500 From: Justin Pryzby To: Jeff Davis Cc: Andres Freund , Tomas Vondra , Melanie Plageman , Heikki Linnakangas , Taylor Vesely , Adam Lee , Melanie Plageman , pgsql-hackers@postgresql.org Subject: Re: Memory-Bounded Hash Aggregation Message-ID: <20200312210146.GG29065@telsasoft.com> References: <20200218185749.srk733n4z57lzxf2@development> <7612ea4d636b6341d0606f4e852d584798e04901.camel@j-davis.com> <20200219191636.gvdywx32kwbix6kd@development> <20200221202212.ssb2qpmdgrnx52sj@alap3.anarazel.de> <9759ab2d0c2c28a175e11efe1788d37dc7e1b768.camel@j-davis.com> <20200222180020.ej5gvfcaf2semgji@alap3.anarazel.de> <5c371df7cee903e8cd4c685f90c6c72086d3a2dc.camel@j-davis.com> <20200224232928.45bcjmdxgnobijgi@alap3.anarazel.de> <6e7c269b9a84ff75fefcad8ab2d4758f03581e98.camel@j-davis.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk On Wed, Mar 11, 2020 at 11:55:35PM -0700, Jeff Davis wrote: > * tweaked EXPLAIN output some more > Unless I (or someone else) finds something significant, this is close > to commit. Thanks for working on this ; I finally made a pass over the patch. +++ b/doc/src/sgml/config.sgml + enable_groupingsets_hash_disk (boolean) + Enables or disables the query planner's use of hashed aggregation for + grouping sets when the size of the hash tables is expected to exceed + work_mem. See . Note that this setting only + affects the chosen plan; execution time may still require using + disk-based hash aggregation. ... ... + enable_hashagg_disk (boolean) + ... This only affects the planner choice; + execution time may still require using disk-based hash + aggregation. The default is on. I don't understand what's meant by "the chosen plan". Should it say, "at execution ..." instead of "execution time" ? + Enables or disables the query planner's use of hashed aggregation plan + types when the memory usage is expected to exceed Either remove "plan types" for consistency with enable_groupingsets_hash_disk, Or add it there. Maybe it should say "when the memory usage would OTHERWISE BE expected to exceed.." +show_hashagg_info(AggState *aggstate, ExplainState *es) +{ + Agg *agg = (Agg *)aggstate->ss.ps.plan; + long memPeakKb = (aggstate->hash_mem_peak + 1023) / 1024; I see this partially duplicates my patch [0] to show memory stats for (at Andres' suggestion) all of execGrouping.c. Perhaps you'd consider naming the function something more generic in case my patch progresses ? I'm using: |show_tuplehash_info(HashTableInstrumentation *inst, ExplainState *es); Mine also shows: |ExplainPropertyInteger("Original Hash Buckets", NULL, |ExplainPropertyInteger("Peak Memory Usage (hashtable)", "kB", |ExplainPropertyInteger("Peak Memory Usage (tuples)", "kB", [0] https://www.postgresql.org/message-id/20200306213310.GM684%40telsasoft.com You added hash_mem_peak and hash_batches_used to struct AggState. In my 0001 patch, I added instrumentation to struct TupleHashTable, and in my 0005 patch I move it into AggStatePerHashData and other State nodes. + if (from_tape) + partition_mem += HASHAGG_READ_BUFFER_SIZE; + partition_mem = npartitions * HASHAGG_WRITE_BUFFER_SIZE; => That looks wrong ; should say += ? + gettext_noop("Enables the planner's use of hashed aggregation plans that are expected to exceed work_mem."), should say: "when the memory usage is otherwise be expected to exceed.." -- Justin