On Thu, Oct 22, 2020 at 4:09 PM Masahiko Sawada <masahiko.saw...@2ndquadrant.com> wrote: > > On Wed, 21 Oct 2020 at 12:56, Amit Kapila <amit.kapil...@gmail.com> wrote: > > > > On Tue, Oct 13, 2020 at 10:33 AM Amit Kapila <amit.kapil...@gmail.com> > > wrote: > > > > > > On Tue, Oct 13, 2020 at 10:21 AM Tom Lane <t...@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.
