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 1jJtS9-0001dr-7G for pgsql-hackers@arkaria.postgresql.org; Thu, 02 Apr 2020 06:35:49 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1jJtS8-0006tg-1w for pgsql-hackers@arkaria.postgresql.org; Thu, 02 Apr 2020 06:35:48 +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 1jJtS7-0006tZ-RX for pgsql-hackers@lists.postgresql.org; Thu, 02 Apr 2020 06:35:47 +0000 Received: from mail-qt1-x82d.google.com ([2607:f8b0:4864:20::82d]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1jJtS4-0007jP-D5 for pgsql-hackers@lists.postgresql.org; Thu, 02 Apr 2020 06:35:47 +0000 Received: by mail-qt1-x82d.google.com with SMTP id z12so2404808qtq.5 for ; Wed, 01 Apr 2020 23:35:43 -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=sB3qfylvtlj2twSrs2goGKUybGkxEOeiM/RlqIrR3lw=; b=y87lsXYmIrV/d0rcPyvPPYkvR6dKKBfyutETPMViYebD+rcuSTpxaR9PDpAu7/7ra9 4sYuMbS++nCj0N82DTHEHPy+aZnhjLZkyh/5+91SocWOzhlo00zO48MDpyxCWWLYwLgK vzLyLv2c/Q1U/efuTl15D996uy/qh+rqfY+2x0mKfm8zmZc6EY7cL+3ocqlvmQGbvHri TWturuQxXgMX7Sv8KGyi0cnU8b2YPHaWpUCxeL2j4FByqNu/y++UMPPutrMl/y58hBY0 nMDhgpeS86mKKBVL2slG5vADhG216PLAkonjCcogsT9ugkN+dzIpvPi7zqz1bgICzWMV IQyQ== 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=sB3qfylvtlj2twSrs2goGKUybGkxEOeiM/RlqIrR3lw=; b=pys9+bT4tcO4vrH1quAQ8SOG+6mIt0kBcie37qimb2OFilMjSIFdkRZhHfIdD8P0Zm aZ1ZpgjGDUIiue5emO0U+Qv68/4wZBM4Eek6kDR+J3gBZaxBMXX7wpEfDTLcflZJUvOv MlnnwMVA0CIp2hS/z2/hNTaru/txVBSjrQxanlCY3ilFPyu0U8KOxHYfI7YT+R9DnKk7 Iv5FL7sTihGOhpQiuwaO/A/7N/LD+R+mtmphWCg1nlGCC4Faepb/u3cmCLJd1z9DsZM7 dfakfv2fV2LCOdrswcb5arEN5D+6pmENlOIacG4Bp3fUtv2FUrEQjk6paCfH/lm30o9y i8WQ== X-Gm-Message-State: AGi0PuY7gaDDslBSWhZwgySMtuXfspM7azP80eqX4mnaVc7FBXz7qGfY zz/seyyPGk5+YPy0jgJKnOg/Zg== X-Google-Smtp-Source: APiQypI7UDVbvYAe4mobmchrltSze+qG2ikxNJjsfldf4dBVvLKJMW2Gvpwcawq+XkMrLUf/a9+2JQ== X-Received: by 2002:aed:24b2:: with SMTP id t47mr1345316qtc.317.1585809342665; Wed, 01 Apr 2020 23:35:42 -0700 (PDT) Received: from pryzbyj (charmander.telsasoft.com. [50.244.222.1]) by smtp.gmail.com with ESMTPSA id t53sm3074809qth.70.2020.04.01.23.35.41 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 01 Apr 2020 23:35:41 -0700 (PDT) Received: by pryzbyj (Postfix, from userid 1000) id 638B6800755; Thu, 2 Apr 2020 01:35:40 -0500 (CDT) Date: Thu, 2 Apr 2020 01:35:40 -0500 From: Justin Pryzby To: Amit Kapila Cc: Kyotaro Horiguchi , PostgreSQL Hackers , Julien Rouhaud , Dilip Kumar , Kirill Bychik , Fujii Masao Subject: Re: User Interface for WAL usage data Message-ID: <20200402063540.GE14618@telsasoft.com> References: <20200402054120.GC14618@telsasoft.com> <20200402.145826.78549992113208057.horikyota.ntt@gmail.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 On Thu, Apr 02, 2020 at 11:32:16AM +0530, Amit Kapila wrote: > On Thu, Apr 2, 2020 at 11:28 AM Kyotaro Horiguchi wrote: > > > > At Thu, 2 Apr 2020 00:41:20 -0500, Justin Pryzby wrote in > > > 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, but I suggest that's not a good example to follow, especially since you're adding a "field" with spaces in it. I thought maybe the "two spaces" convention predated "Buffers". But sort has had two spaces since it was added 2009-08-10 (9bd27b7c9). Buffers since it was added 2009-12-15 (cddca5ec). And buckets since it was added 2010-02-01 (42a8ab0a). -- Justin