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? 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
