From: Julien Rouhaud <rjuju123@gmail.com>
To: Amit Kapila <amit.kapila16@gmail.com>
Cc: Dilip Kumar <dilipbalaut@gmail.com>
Cc: Kuntal Ghosh <kuntalghosh.2007@gmail.com>
Cc: Fujii Masao <masao.fujii@oss.nttdata.com>
Cc: Kirill Bychik <kirill.bychik@gmail.com>
Cc: PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Cc: Thomas Munro <thomas.munro@gmail.com>
Subject: Re: WAL usage calculation patch
Date: Sat, 4 Apr 2020 08:03:03 +0200
Message-ID: <20200404060303.n2q74lbccjm2swdc@nol> (raw)
In-Reply-To: <CAA4eK1+sSXvf45x6CbXTEywzXLNcuwWUy-m1rg2KyJKcEXBPvw@mail.gmail.com>
References: <20200402124818.GD64485@nol>
<CAA4eK1LNg7Q6pxrochATMSJmadrzPKJODGAAxbgmgnWbi63UNw@mail.gmail.com>
<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>
On Sat, Apr 04, 2020 at 10:38:14AM +0530, Amit Kapila wrote:
> On Fri, Apr 3, 2020 at 7:36 PM Amit Kapila <amit.kapila16@gmail.com> wrote:
> >
> > On Fri, Apr 3, 2020 at 9:40 AM Amit Kapila <amit.kapila16@gmail.com> wrote:
> > >
> > > On Fri, Apr 3, 2020 at 9:35 AM Dilip Kumar <dilipbalaut@gmail.com> wrote:
> > > >
> > > > I have analyzed the WAL and there could be multiple reasons for the
> > > > same. With small data, I have noticed that while inserting in the
> > > > system index there was a Page Split and that created extra WAL.
> > > >
> > >
> > > Thanks for the investigation. I think it is clear that we can't
> > > expect the same WAL size even if we repeat the same operation unless
> > > it is a fresh database.
> > >
> >
> > Attached find the latest patches. I have modified based on our
> > discussion on user interface thread [1], ran pgindent on all patches,
> > slightly modified one comment based on Dilip's input and added commit
> > messages. I think the patches are in good shape. I would like to
> > commit the first patch in this series tomorrow unless I see more
> > comments or any other objections.
> >
>
> Pushed.
Thanks!
> > 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. 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?
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: rjuju123@gmail.com, amit.kapila16@gmail.com, dilipbalaut@gmail.com, kuntalghosh.2007@gmail.com, masao.fujii@oss.nttdata.com, kirill.bychik@gmail.com, thomas.munro@gmail.com
Subject: Re: WAL usage calculation patch
In-Reply-To: <20200404060303.n2q74lbccjm2swdc@nol>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox