Re: Resetting spilled txn statistics in pg_stat_replication

On Tue, Oct 27, 2020 at 06:19:42PM -0500, Justin Pryzby wrote:
>On Tue, Oct 27, 2020 at 09:17:43AM +0530, Amit Kapila wrote:
>> On Tue, Oct 27, 2020 at 8:51 AM Justin Pryzby <pryzby(at)telsasoft(dot)com> wrote:
>> >
>> > On Fri, Oct 23, 2020 at 10:45:34AM +0530, Amit Kapila wrote:
>> > > On Fri, Oct 23, 2020 at 8:59 AM Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
>> > >
>> > > While updating the streaming stats patch, it occurred to me that we
>> > > can write a better description spill_bytes as well. Attached contains
>> > > the update to spill_bytes description.
>> >
>> > + This and other spill
>> > + counters can be used to gauge the I/O occurred during logical decoding
>> > + and accordingly can tune <literal>logical_decoding_work_mem</literal>.
>> >
>> > "gauge the IO occurred" is wrong.
>> > Either: I/O *which* occured, or I/O occurring, or occurs.
>> >
>> > "can tune" should say "allow tuning".
>> >
>> > Like:
>> > + This and other spill
>> > + counters can be used to gauge the I/O which occurs during logical decoding
>> > + and accordingly allow tuning of <literal>logical_decoding_work_mem</literal>.
>> >
>> > - Number of times transactions were spilled to disk. Transactions
>> > + Number of times transactions were spilled to disk while performing
>> > + decoding of changes from WAL for this slot. Transactions
>> >
>> > What about: "..while decoding changes.." (remove "performing" and "of").
>> >
>>
>> All of your suggestions sound good to me. Find the patch attached to
>> update the docs accordingly.
>
>@@ -2628,8 +2627,8 @@ SELECT pid, wait_event_type, wait_event FROM pg_stat_activity WHERE wait_event i
> <para>
> Amount of decoded transaction data spilled to disk while performing
> decoding of changes from WAL for this slot. This and other spill
>- counters can be used to gauge the I/O occurred during logical decoding
>- and accordingly can tune <literal>logical_decoding_work_mem</literal>.
>+ counters can be used to gauge the I/O which occurred during logical
>+ decoding and accordingly allow tuning <literal>logical_decoding_work_mem</literal>.
>
>Now that I look again, maybe remove "accordingly" ?
>

Yeah, the 'accordingly' seems rather unnecessary here. Let's remove it.

FWIW thanks to everyone working on this and getting the reworked version
of the 9290ad198b patch in. As an author of that patch I should have
paid more attention to this thread, and I appreciate the amount of work
spent on fixing it.

regards

--
Tomas Vondra http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services