Re: Resetting spilled txn statistics in pg_stat_replication

On Tue, Oct 13, 2020 at 10:21 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> writes:
> > On Tue, Oct 13, 2020 at 9:25 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> >> It's not very clear what spill_count actually counts (and the
> >> documentation sure does nothing to clarify that), but if it has anything
> >> to do with WAL volume, the explanation might be that florican is 32-bit.
> >> All the animals that have passed that test so far are 64-bit.
>
> prairiedog just failed in not-quite-the-same way, which reinforces the
> idea that this test is dependent on MAXALIGN, which determines physical
> tuple size. (I just checked the buildfarm, and the four active members
> that report MAXALIGN 4 during configure are florican, lapwing, locust,
> and prairiedog. Not sure about the MSVC critters though.) The
> spill_count number is different though, so it seems that that may not
> be the whole story.
>

It is possible that MAXALIGN stuff is playing a role here and or the
background transaction stuff. I think if we go with the idea of
testing spill_txns and spill_count being positive then the results
will be stable. I'll write a patch for that.

> > It is based on the size of the change. In this case, it is the size of
> > the tuples inserted. See ReorderBufferChangeSize() know how we compute
> > the size of each change.
>
> 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.

--
With Regards,
Amit Kapila.