Date: Sat, 4 Apr 2020 10:54:23 +0200
From: Julien Rouhaud <rjuju123@gmail.com>
To: Amit Kapila <amit.kapila16@gmail.com>
Cc: Dilip Kumar <dilipbalaut@gmail.com>,
	Kuntal Ghosh <kuntalghosh.2007@gmail.com>,
	Fujii Masao <masao.fujii@oss.nttdata.com>,
	Kirill Bychik <kirill.bychik@gmail.com>,
	PostgreSQL Hackers <pgsql-hackers@postgresql.org>,
	Thomas Munro <thomas.munro@gmail.com>
Subject: Re: WAL usage calculation patch
Message-ID: <20200404085423.GC1206@nol>
References: 
 <CAFiTN-sHQ-bHwqEYOVOMjZ7VoQafWKLaTYiWvf-rR+twZ4LOwQ@mail.gmail.com>
 <CAFiTN-sONFPUHxMpn9m4=Z+m_MubCdvcVD75+QRK5jxVmUce8w@mail.gmail.com>
 <CAA4eK1LjkwGOegWMfs3tggD3-BXLzyZXFz7qBZaf_yLBPjZdHQ@mail.gmail.com>
 <CAFiTN-su_D35-csorD=soxnkL=g9ZVdnTN3QfPfK_TNp2t4Kug@mail.gmail.com>
 <CAFiTN-vAqkDV5Whxw2OvdbN9OU7xZyKzRrUG6m6dr8nvG-R=Yw@mail.gmail.com>
 <CAA4eK1Jh=EjwK+etqeaWM6gcNaex1FX6xTFqR7QXXQy2CmGQsw@mail.gmail.com>
 <CAA4eK1KqiWqAgw9ETchcQf-z9ZY4aUN-4QvTh0R26+DpNnTDHg@mail.gmail.com>
 <CAA4eK1+sSXvf45x6CbXTEywzXLNcuwWUy-m1rg2KyJKcEXBPvw@mail.gmail.com>
 <20200404060303.n2q74lbccjm2swdc@nol>
 <CAA4eK1Kep_Wv1ZK+ODLhioPdP8VD4HuHx5d-C2h9s83yriYejg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
 <CAA4eK1Kep_Wv1ZK+ODLhioPdP8VD4HuHx5d-C2h9s83yriYejg@mail.gmail.com>
Precedence: bulk

On Sat, Apr 04, 2020 at 02:12:59PM +0530, Amit Kapila wrote:
> On Sat, Apr 4, 2020 at 11:33 AM Julien Rouhaud <rjuju123@gmail.com> wrote:
> >
> > On Sat, Apr 04, 2020 at 10:38:14AM +0530, Amit Kapila wrote:
> >
> > > >  The patch-2 might need to be
> > > > rebased if the other related patch [2] got committed first and we
> > > > might need to tweak a bit based on the input from other thread [1]
> > > > where we are discussing user interface for it.
> > > >
> > >
> > > The primary question for patch-2 is whether we want to include WAL
> > > usage information for the planning phase as we did for BUFFERS in
> > > recent commit ce77abe63c (Include information on buffer usage during
> > > planning phase, in EXPLAIN output, take two.).  Initially, I thought
> > > it might be a good idea to do the same for WAL but after reading the
> > > thread that leads to commit, I am not sure if there is any pressing
> > > need to include WAL information for the planning phase.  Because
> > > during planning we might not write much WAL (with the exception of WAL
> > > due to setting of hint-bits) so users might not care much.  What do
> > > you think?
> >
> >
> > I agree that WAL activity during planning shouldn't be very frequent, but it
> > might still be worthwhile to add it.
> >
> 
> 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.


> 
> >  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.  I thought that's why you
were hesitating of adding it.