On Sat, Apr 04, 2020 at 02:39:32PM +0530, Amit Kapila wrote: > On Sat, Apr 4, 2020 at 2:24 PM Julien Rouhaud <rjuju...@gmail.com> wrote: > > > > > > We can add if we want but I am not able to convince myself for that. > > > Do you have any use case in mind? I think in most of the cases > > > (except for hint-bit WAL) it will be zero. If we are not sure of this > > > we can also discuss it separately in a new thread once this > > > patch-series is committed and see if anybody else sees the value of it > > > and if so adding the code should be easy. > > > > > > I'm mostly thinking of people trying to investigate possible slowdowns on a > > hot-standby replica with a primary without wal_log_hints. If they > > explicitly > > ask for WAL information, we should provide them, even if it's quite > > unlikely to > > happen. > > > > Yeah, possible but I am not completely sure. I would like to hear the > opinion of others if any before adding code for this. How about if we > first commit pg_stat_statements and wait for this till Monday and if > nobody responds we can commit the current patch but would start a new > thread and try to get the opinion of others?
I'm fine with it. > > > > > > > > > > I'm wondering how stable the normalized > > > > WAL information would be in some regression tests, as the counters are > > > > only > > > > showed if non zero. Maybe it'd be better to remove them from the > > > > output, same > > > > as the buffers? > > > > > > > > > > Which regression tests are you referring to? pg_stat_statements? If > > > so, why would it be unstable? It should always generate WAL although > > > the exact values may differ and we have already taken care of that in > > > the patch, no? > > > > > > I'm talking about a hypothetical new EXPLAIN (ALAYZE, WAL) regression test, > > which could be unstable for similar reason to why the first attempt to add > > BUFFERS in the planning part of EXPLAIN was unstable. > > > > oh, then leave it for now because I don't see much use of those as the > code path can anyway be hit by the tests added by pg_stat_statements > patch. > Perfect then!
