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? 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.
Regards,
--
Masahiko Sawada http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services