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 1jCnvd-0004qo-3o for pgsql-hackers@arkaria.postgresql.org; Fri, 13 Mar 2020 17:16:57 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1jCnud-0002FQ-7l for pgsql-hackers@arkaria.postgresql.org; Fri, 13 Mar 2020 17:15:55 +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 1jCnuc-0002FI-OL for pgsql-hackers@lists.postgresql.org; Fri, 13 Mar 2020 17:15:54 +0000 Received: from mail-pl1-x62d.google.com ([2607:f8b0:4864:20::62d]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1jCnuZ-0002qn-OP for pgsql-hackers@lists.postgresql.org; Fri, 13 Mar 2020 17:15:53 +0000 Received: by mail-pl1-x62d.google.com with SMTP id ay11so4566162plb.0 for ; Fri, 13 Mar 2020 10:15:51 -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=LbHsbd9rbocIkqLtI4n61TrtiYhjrHOH9JbHdDm4SgE=; b=ri7P5y4r+aJb1ZMlKs/0qMd+U+UQ8+5hkHf9ueMYPlzln1T82BINmeNSEs+1HLHZzO HL4yWg6nBhC4FYneKDSHteV3tU/m46aj5hv5+uvKJaWHOx8iWEWE81S8rz6QfyYThUU8 rp1acedYLj35pYZYESrK6gkzqzky00vCg5/Q208qlYvIALMWXYIUp7y3v0UzlGd9hCOE gTorwuHCF6jq/6nvvFYaE9xJ+ZNdSogxVlXphc8Hcq3FntIt+EP6GdRTDjCYf2RbgfX0 rRYc9ZYEO/se4tocLLTcghslvf/MTJPNX3a08HkchMAQn2ugnWNQpYOu2iVr9pfcRDj7 r9Ig== 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=LbHsbd9rbocIkqLtI4n61TrtiYhjrHOH9JbHdDm4SgE=; b=CjZTb7YnB7RQOKllVPx3TFS1wUEoGvDTJeAd3JJktWfPVzM441VIe6c2gPpZFLA6+B nFfx/vaTaigaJVxpCW83Qk4+smXPbyEE7Dj0OIEwMHMiRE+ors1H4vRK08kGUTmG1KKv TZt6N38u0feJnEaRhpqfSx/94rE6Ki119l4K+jj/E3S6RKkB4ocQxRkZbiH4o9UOEtrl jokVv4YvbpWKmu2hGZ/VTYxeli3i7hu92z29u0FW2Gt5w5JYpFF4klzeLIy9hVLJgp7b odkgwJABw6axrkalC04hViwxw3wb/KZWPbWhjqdxeWFqZSt6tHOCfedHXmDG91lwMClJ vhlQ== X-Gm-Message-State: ANhLgQ0tRTFhhlFqu0oQLKGcEAnbIYit4n6SyWRDIOp5ICKcjLRmXrYT 9ozb803IVtHAredC/5Gr80Sm2g== X-Google-Smtp-Source: ADFU+vsCnIIIf/2SkZLHKaR58RSPwf5eyRvH0wYK5lXaXMMtIY3ZVHCs8w+CikwUiUlWV8frIv56pQ== X-Received: by 2002:a17:90a:a590:: with SMTP id b16mr11144251pjq.61.1584119750269; Fri, 13 Mar 2020 10:15:50 -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 k3sm16852815pfp.142.2020.03.13.10.15.48 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Fri, 13 Mar 2020 10:15:49 -0700 (PDT) Message-ID: Subject: Re: explain HashAggregate to report bucket and memory stats From: Jeff Davis To: Justin Pryzby , Andres Freund Cc: Tomas Vondra , pgsql-hackers@lists.postgresql.org, Jeff Janes Date: Fri, 13 Mar 2020 10:15:46 -0700 In-Reply-To: <20200306213310.GM684@telsasoft.com> References: <20200103161925.GM12066@telsasoft.com> <20200203145301.53mozz7gcdaklnjc@alap3.anarazel.de> <20200216000220.GF31889@telsasoft.com> <20200216175307.GJ31889@telsasoft.com> <20200219201037.GA21433@telsasoft.com> <20200222215335.bu4kky7el4nccls5@development> <20200225033532.GX31889@telsasoft.com> <20200301154540.GL29456@telsasoft.com> <20200306175859.d56ohskarwldyrrw@alap3.anarazel.de> <20200306213310.GM684@telsasoft.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.28.5-0ubuntu0.18.04.1 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk + /* hashtable->entrysize includes additionalsize */ + hashtable->instrument.space_peak_hash = Max( + hashtable->instrument.space_peak_hash, + hashtable->hashtab->size * sizeof(TupleHashEntryData)); + + hashtable->instrument.space_peak_tuples = Max( + hashtable->instrument.space_peak_tuples, + hashtable->hashtab->members * hashtable->entrysize); I think, in general, we should avoid estimates/projections for reporting and try to get at a real number, like MemoryContextMemAllocated(). (Aside: I may want to tweak exactly what that function reports so that it doesn't count the unused portion of the last block.) For instance, the report is still not accurate, because it doesn't account for pass-by-ref transition state values. To use memory-context-based reporting, it's hard to make the stats a part of the tuple hash table, because the tuple hash table doesn't own the memory contexts (they are passed in). It's also hard to make it per-hashtable (e.g. for grouping sets), unless we put each grouping set in its own memory context. Also, is there a reason you report two different memory values (hashtable and tuples)? I don't object, but it seems like a little too much detail. Regards, Jeff Davis