On Tue, Apr 7, 2020 at 3:30 PM Peter Eisentraut <peter.eisentr...@2ndquadrant.com> wrote: > > On 2020-04-07 04:12, Amit Kapila wrote: > > On Mon, Apr 6, 2020 at 10:01 PM Justin Pryzby <pry...@telsasoft.com> wrote: > >> > >> On Mon, Apr 06, 2020 at 05:01:30PM +0200, Peter Eisentraut wrote: > >>> I noticed in some of the screenshots that were tweeted that for example in > >>> > >>> WAL: records=1 bytes=56 > >>> > >>> there are two spaces between pieces of data. This doesn't match the rest > >>> of > >>> the EXPLAIN output. Can that be adjusted? > >> > >> We talked about that here: > >> https://www.postgresql.org/message-id/20200402054120.GC14618%40telsasoft.com > >> > > > > Yeah. Just to brief here, the main reason was that one of the fields > > (full page writes) already had a single space and then we had prior > > cases as mentioned in Justin's email [1] where we use two spaces which > > lead us to decide using two spaces in this case. > > We also have existing cases for the other way: > > actual time=0.050..0.052 > Buffers: shared hit=3 dirtied=1 >
Buffers case is not the same because 'shared' is used for 'hit', 'read', 'dirtied', etc. However, I think it is arguable. > 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. > Sure, I think my intention is to keep the format of WAL stats as close to Buffers stats as possible because both depict I/O and users would probably be interested to check/read both together. There is a point to keep things in a format so that it is easier for someone to parse but I guess as these as fixed 'words', it shouldn't be difficult either way and we should give more weightage to consistency. Any suggestions? -- With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com
