Date: Tue, 7 Apr 2020 17:50:34 -0500
From: Justin Pryzby <pryzby@telsasoft.com>
To: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
Cc: Amit Kapila <amit.kapila16@gmail.com>,
	Dilip Kumar <dilipbalaut@gmail.com>,
	Julien Rouhaud <rjuju123@gmail.com>,
	Kuntal Ghosh <kuntalghosh.2007@gmail.com>,
	Fujii Masao <masao.fujii@oss.nttdata.com>,
	Kirill Bychik <kirill.bychik@gmail.com>,
	pgsql-hackers@postgresql.org, Thomas Munro <thomas.munro@gmail.com>
Subject: Re: WAL usage calculation patch
Message-ID: <20200407225034.GV2228@telsasoft.com>
References: 
 <CAFiTN-sONFPUHxMpn9m4=Z+m_MubCdvcVD75+QRK5jxVmUce8w@mail.gmail.com>
 <CAA4eK1LjkwGOegWMfs3tggD3-BXLzyZXFz7qBZaf_yLBPjZdHQ@mail.gmail.com>
 <CAFiTN-su_D35-csorD=soxnkL=g9ZVdnTN3QfPfK_TNp2t4Kug@mail.gmail.com>
 <CAFiTN-vAqkDV5Whxw2OvdbN9OU7xZyKzRrUG6m6dr8nvG-R=Yw@mail.gmail.com>
 <CAA4eK1Jh=EjwK+etqeaWM6gcNaex1FX6xTFqR7QXXQy2CmGQsw@mail.gmail.com>
 <CAA4eK1KqiWqAgw9ETchcQf-z9ZY4aUN-4QvTh0R26+DpNnTDHg@mail.gmail.com>
 <ef8c966f-e50a-c583-7b1e-85de6f4ca0d3@2ndquadrant.com>
 <20200406163109.GD2228@telsasoft.com>
 <CAA4eK1+Gwy=-teh7dGYY03qsYVAekHfokie8LWSwGXOGp3YOMw@mail.gmail.com>
 <61b66de7-ebb3-fada-b6d3-243386976631@2ndquadrant.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <61b66de7-ebb3-fada-b6d3-243386976631@2ndquadrant.com>
User-Agent: Mutt/1.9.4 (2018-02-28)
Precedence: bulk

On Tue, Apr 07, 2020 at 12:00:29PM +0200, Peter Eisentraut wrote:
> We also have existing cases for the other way:
> 
>     actual time=0.050..0.052
>     Buffers: shared hit=3 dirtied=1
> 
> The cases mentioned by Justin are not formatted in a key=value format, so
> it's not quite the same, but it also raises the question why they are not.
> 
> Let's figure out a way to consolidate this without making up a third format.

So this re-raises my suggestion here to use colons, Title Case Field Names, and
"Size: ..kB" rather than "bytes=":
|https://www.postgresql.org/message-id/20200403054451.GN14618%40telsasoft.com

As I see it, the sort/hashjoin style is being used for cases with fields with
different units:

   Sort Method: quicksort  Memory: 931kB
   Buckets: 1024  Batches: 1  Memory Usage: 16kB

..which is distinguished from the case where the units are the same, like
buffers (hit=Npages read=Npages dirtied=Npages written=Npages).

Note, as of 1f39bce021, we have hashagg_disk, which looks like this:

template1=# explain analyze SELECT a, COUNT(1) FROM generate_series(1,99999) a GROUP BY 1 ORDER BY 1;
...
   ->  HashAggregate  (cost=1499.99..1501.99 rows=200 width=12) (actual time=166.883..280.943 rows=99999 loops=1)
         Group Key: a
         Peak Memory Usage: 4913 kB
         Disk Usage: 1848 kB
         HashAgg Batches: 8

Incremental sort adds yet another variation, which I've mentioned that thread.
I'm hoping to come to some resolution here, first.
https://www.postgresql.org/message-id/20200407042521.GH2228%40telsasoft.com

-- 
Justin