On Thu, Oct 22, 2020 at 4:09 PM Masahiko Sawada
<masahiko.sawada@2ndquadrant.com> wrote:
>
> On Wed, 21 Oct 2020 at 12:56, Amit Kapila <amit.kapila16@gmail.com> wrote:
> >
> > On Tue, Oct 13, 2020 at 10:33 AM Amit Kapila <amit.kapila16@gmail.com> wrote:
> > >
> > > On Tue, Oct 13, 2020 at 10:21 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> > > >
> > > >
> > > > I know I can go read the source code, but most users will not want to.
> > > > Is the documentation in monitoring.sgml really sufficient? If we can't
> > > > explain this with more precision, is it really a number we want to expose
> > > > at all?
> > > >
> > >
> > > This counter is important to give users an idea about the amount of
> > > I/O we incur during decoding and to tune logical_decoding_work_mem
> > > GUC. So, I would prefer to improve the documentation for this
> > > variable.
> > >
> >
> > I have modified the description of spill_count and spill_txns to make
> > things clear. Any suggestions?
>
> Thank you for the patch.
>
> - logical decoding exceeds
> <literal>logical_decoding_work_mem</literal>. The
> - counter gets incremented both for toplevel transactions and
> - subtransactions.
> + logical decoding of changes from WAL for this exceeds
> + <literal>logical_decoding_work_mem</literal>. The counter gets
> + incremented both for toplevel transactions and subtransactions.
>
> What is the word "this" in the above change referring to?
>
'slot'. The word *slot* is missing in the sentence.
> How about
> something like:
>
> Number of transactions spilled to disk after the memory used by
> logical decoding of changes from WAL exceeding
> logical_decoding_work_mem. The counter gets incremented both for
> toplevel transactions and subtransactions.
>
/exceeding/exceeds. I am fine with your proposed text as well but if
you like the above after correction that would be better because it
would be more close to spill_count description.
--
With Regards,
Amit Kapila.
