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 1jlurB-0007oy-EN for pgsql-hackers@arkaria.postgresql.org; Thu, 18 Jun 2020 13:45: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 1jlurA-0004ra-07 for pgsql-hackers@arkaria.postgresql.org; Thu, 18 Jun 2020 13:45:28 +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 1jlur9-0004rR-KH for pgsql-hackers@lists.postgresql.org; Thu, 18 Jun 2020 13:45:27 +0000 Received: from mail-il1-x12d.google.com ([2607:f8b0:4864:20::12d]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1jlur0-0007l3-6N for pgsql-hackers@lists.postgresql.org; Thu, 18 Jun 2020 13:45:26 +0000 Received: by mail-il1-x12d.google.com with SMTP id p5so5796147ile.6 for ; Thu, 18 Jun 2020 06:45:17 -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=x37fOIhbFuROQ1J94k9KsFid8E6o0H2cy1kdPW5DyU0=; b=P0BCJ5Nx394dA29hpQVoTknS43demrx0aPUP188sQa39mZYjzeL9IVdKJ04HhB3sMd xKmfFN7lHx0uomVO7dgKXF2MHOhnzlcmALaB7AnDLqReXfvZ6bHMYnrff3ETJ2SxqyTa ni3TPOfO7dDZ127D/0ir3k4+oz0W1mChs9bTXQlF6MPIPctzlMjUH0V7ktHv3YOjCFsV GBnVNZhVpZvZ8k8wpW7zXnWgAMKuZ7rOOTEB+1QwZL+sDI1vFSsOMXE4X1TYEmqlZf5I Bp90/TMVfvv20pqRJ6OfCL+WzkmwRTd0aL8fRv9xXVGTbaI8jrp4G35rm5TL1yTR6ppK zy+Q== 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=x37fOIhbFuROQ1J94k9KsFid8E6o0H2cy1kdPW5DyU0=; b=k0roGn+H+6ErjHviVUXq9VHhsA6z28FcWnOnmA5JjUMnJ2UNyNfFSP+xUwFbPBQKJA lSHwLlkdMHJzwQl6bO9iPC6tGmWajdJmXccwaKKweCPSdT3NZP8vSGJl136hCT9TlEyF arBBBb4oG8ldBi8S8eTlwQlIrH+T7JTr/GfhAHMT0FuPwyWgVu7ynly9Y2B75AW52DJP OANvtyZHGAu/1kwXJuTiPZ9jo030DRxm1q6VmcV72jGWPgeey9JNH0u4n1/nKJ3atj3a sJQ1WVHWkcUbMfq8qjIF5NrDbSJtW4kmjZu7Q6JF9ROGmYCvMd+G80lqfHxba0iH3rk5 CP4g== X-Gm-Message-State: AOAM530iBxE8jqDmA7EmNQtBlK0uUJSkqIKeyAERyd7BBRukvPiEIFNU 2gj4j+VwFXLLdWOTy6BaPpjLXA== X-Google-Smtp-Source: ABdhPJxdtmG98wN/EpZDAMcoHHQVnFRcZWNxd7LS7EiOCaQQL8OTVrOB66ICJ7/7NBqfXausGvtehg== X-Received: by 2002:a05:6e02:92:: with SMTP id l18mr1747235ilm.212.1592487916387; Thu, 18 Jun 2020 06:45:16 -0700 (PDT) Received: from pryzbyj.telsasoft (charmander.telsasoft.com. [50.244.222.1]) by smtp.gmail.com with ESMTPSA id y6sm1498910ilj.56.2020.06.18.06.45.15 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 18 Jun 2020 06:45:15 -0700 (PDT) Received: by pryzbyj.telsasoft (Postfix, from userid 1000) id 75CED800153; Thu, 18 Jun 2020 08:45:14 -0500 (CDT) Date: Thu, 18 Jun 2020 08:45:14 -0500 From: Justin Pryzby To: David Rowley Cc: pgsql-hackers@lists.postgresql.org, Jeff Davis Subject: Re: Missing HashAgg EXPLAIN ANALYZE details for parallel plans Message-ID: <20200618134514.GF17995@telsasoft.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk On Thu, Jun 18, 2020 at 03:37:21PM +1200, David Rowley wrote: > Now that HashAgg can spill to disk, we see a few more details in > EXPLAIN ANALYZE than we did previously, e.g. Peak Memory Usage, Disk > Usage. However, the new code neglected to make EXPLAIN ANALYZE show > these new details for parallel workers. > > Additionally, the new properties all were using > ExplainPropertyInteger() which meant that we got output like: > > Group Key: a > Peak Memory Usage: 97 kB > Disk Usage: 3928 kB > HashAgg Batches: 798 > > Where all the properties were on a line by themselves. This does not > really follow what other nodes are doing, e.g sort: > > -> Sort (actual time=47.500..59.344 rows=100000 loops=1) > Sort Key: a > Sort Method: external merge Disk: 2432kB > > Where we stick all the properties on a single line. Note that "incremental sort" is also new, and splits things up more than sort. See in particular 6a918c3ac8a6b1d8b53cead6fcb7cbd84eee5750, which splits things up even more. -> Incremental Sort (actual rows=70 loops=1) Sort Key: t.a, t.b Presorted Key: t.a - Full-sort Groups: 1 Sort Method: quicksort Memory: avg=NNkB peak=NNkB Presorted Groups: 5 Sort Methods: top-N heapsort, quicksort Memory: avg=NNkB peak=NNkB + Full-sort Groups: 1 Sort Method: quicksort Average Memory: NNkB Peak Memory: NNkB + Pre-sorted Groups: 5 Sort Methods: top-N heapsort, quicksort Average Memory: NNkB Peak Memory: NNkB That's not really a "precedent" and I don't think that necessarily invalidates your change. -- Justin