Re: Resetting spilled txn statistics in pg_stat_replication - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Resetting spilled txn statistics in pg_stat_replication
Date
Msg-id 3411152.1602564678@sss.pgh.pa.us
Whole thread Raw
In response to Re: Resetting spilled txn statistics in pg_stat_replication  (Amit Kapila <amit.kapila16@gmail.com>)
Responses Re: Resetting spilled txn statistics in pg_stat_replication  (Amit Kapila <amit.kapila16@gmail.com>)
Re: Resetting spilled txn statistics in pg_stat_replication  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Amit Kapila <amit.kapila16@gmail.com> writes:
> On Tue, Oct 13, 2020 at 9:25 AM Tom Lane <tgl@sss.pgh.pa.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 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?

            regards, tom lane



pgsql-hackers by date:

Previous
From: Amit Langote
Date:
Subject: Re: partition routing layering in nodeModifyTable.c
Next
From: Dilip Kumar
Date:
Subject: Re: [HACKERS] Custom compression methods