On Thu, Apr 2, 2020 at 12:05 PM Justin Pryzby <pry...@telsasoft.com> wrote: > > On Thu, Apr 02, 2020 at 11:32:16AM +0530, Amit Kapila wrote: > > On Thu, Apr 2, 2020 at 11:28 AM Kyotaro Horiguchi <horikyota....@gmail.com> > > wrote: > > > > > > At Thu, 2 Apr 2020 00:41:20 -0500, Justin Pryzby <pry...@telsasoft.com> > > > 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. >
Agreed, this is a good reason to keep two spaces as we have in cases of Buckets. We can display the variable as "full page writes". -- With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com
