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 1jKEby-0007P8-Ox for pgsql-hackers@arkaria.postgresql.org; Fri, 03 Apr 2020 05:11:22 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1jKEbw-0006kk-8K for pgsql-hackers@arkaria.postgresql.org; Fri, 03 Apr 2020 05:11:20 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jKEbv-0006kI-TX for pgsql-hackers@lists.postgresql.org; Fri, 03 Apr 2020 05:11:20 +0000 Received: from mail-qk1-x732.google.com ([2607:f8b0:4864:20::732]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1jKEbs-0007YE-Tq for pgsql-hackers@lists.postgresql.org; Fri, 03 Apr 2020 05:11:18 +0000 Received: by mail-qk1-x732.google.com with SMTP id y3so1996814qky.8 for ; Thu, 02 Apr 2020 22:11:16 -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=7mi49e/2KLecrdzLrZznG+LLblkwEJKC/0c4TtlFKBs=; b=WQPIOOWBF4lkLU8VUHs499YDqEiRYoJ22kZQOHj6D/r0AvBHmYVG4bsZ/xmNor6eD1 R/FXFQbLd8H8cIdjpvjIUNCit14IX/zy7Xv43f0jH1f/346xAqF17jq4mcWLnGk6Rffp j6qPr4oVXYgrNn0HOChe6vXvYQfJscSZeSMvOaEYTzKATEJ9MgyElfN0w0Bp0mzu95gn eISY2VPv5KehvCIklvCPsZMjqvol7l3gfwXkH7iGju0fEyOiMn/tB4aWcL7cg5iuKGyL xBGFXWFaQFDGIvFwhMvcmJLVsVIm5nwWrev7IVb6gWEp65Xgp/bHiwa63U5oovZ6F9C3 mKPw== 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=7mi49e/2KLecrdzLrZznG+LLblkwEJKC/0c4TtlFKBs=; b=uoF6J9i2QpIwVSbuGxLeDwx1tF+54529yz/btt8A1h9vBYuLK63wmvMAoIR75xSF04 vr6pwTTOhYi74S2+JT52eSzVwqsY7FuZxN9XkCvvmFixv2i94RXjcVQbgHlSBe0/75+A FAiz45ze8vVQ3RFCLaeF8hS1RX3vaOd1msHAEUuXWrQlVPLCbF1XtsCDfhHtS8ekBwf/ mEBN5WCB0ZXFnnmL/YK5i/o3YX5twIYo0H2lxjE7CSB01e4XHP4DfItCRlpVOTGXBSkj n67URZ3x3jAwhV4gsVHyoFwVnxZkKkgcnHoxgK22xx/rOgOYyiCga/a89YiuQTD85Abo kpqQ== X-Gm-Message-State: AGi0PuYp/8zLaGUE8pmS30LhIfsK+MPwsp6eJnkiS/ljvFkB5RO74d/O UzqzSkTVRizH4ogAVnHT9g878Q== X-Google-Smtp-Source: APiQypLON4ad1alLW7YzBRa9FZh0VhyHggN/AxlE6SYbe0JUu/mcaWbAChixPqbk46+JoLp364tPnw== X-Received: by 2002:a37:bd81:: with SMTP id n123mr6995434qkf.269.1585890675626; Thu, 02 Apr 2020 22:11:15 -0700 (PDT) Received: from pryzbyj (charmander.telsasoft.com. [50.244.222.1]) by smtp.gmail.com with ESMTPSA id x37sm5719423qtc.90.2020.04.02.22.11.14 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 02 Apr 2020 22:11:14 -0700 (PDT) Received: by pryzbyj (Postfix, from userid 1000) id 3B20C80092E; Fri, 3 Apr 2020 00:11:12 -0500 (CDT) Date: Fri, 3 Apr 2020 00:11:12 -0500 From: Justin Pryzby To: Amit Kapila Cc: Kyotaro Horiguchi , pgsql-hackers@lists.postgresql.org, Julien Rouhaud , Dilip Kumar , Kirill Bychik , Fujii Masao Subject: Re: User Interface for WAL usage data Message-ID: <20200403051111.GM14618@telsasoft.com> References: <20200402054120.GC14618@telsasoft.com> <20200402.145826.78549992113208057.horikyota.ntt@gmail.com> <20200402063540.GE14618@telsasoft.com> 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 > > > > > Regarding v10-0004-Add-option-to-report-WAL-usage-in-EXPLAIN-and-au.patch: > > > > > I think there should be additional spaces before "full" and before "bytes": > > > > > > > > > > > WAL: records=2359 full page records=42 bytes=447788 > > > > > > > > > > Compare with these: > > > > > > > > > > "Sort Method: %s %s: %ldkB\n", > > > > > "Buckets: %d (originally %d) Batches: %d (originally %d) Memory Usage: %ldkB\n", > > > > > "Buckets: %d Batches: %d Memory Usage: %ldkB\n", > > > > > > > > > > Otherwise "records=2359 full page records=42" is hard to parse. > > > > > > > > I got the same feeling seeing the line. > > > > > > But isn't this same as we have BufferUsage data? We can probably > > > display it as full_page_writes or something like that. > > > > I guess you mean this: > > Buffers: shared hit=994 read=11426 dirtied=466 > > > > Which can show shared/local/temp. Actually I would probably make the same > > suggestion for "Buffers" (if it were a new patch). I would find this to be > > pretty unfriendly output: > > > > Buffers: shared hit=12345 read=12345 dirtied=12345 local hit=12345 read=12345 dirtied=12345 temp hit=12345 read=12345 dirtied=12345 > > > > Adding two extra spaces " local" and " temp" would have helped there, so > > would commas, or parenthesis, dashes or almost anything - other than a > > backslash. > > > > So I think you're right that WAL is very similar to the Buffers case[...] Actually, I take that back. If I understand correctly, there should be two spaces not only to make the 2nd field more clear, but because the three values have different units: > > > > > > WAL: records=2359 full page records=42 bytes=447788 1) records; 2) pages ("full page images"); 3) bytes That is exactly like sort (method/type/size) and hash (buckets/batches/size), and *not* like buffers, which shows various values all in units of "pages". -- Justin