Re: WAL usage calculation patch

On Sat, Apr 4, 2020 at 2:24 PM Julien Rouhaud <rjuju123(at)gmail(dot)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 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.

--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com