On Thu, Jul 14, 2022 at 4:31 PM Andres Freund <and...@anarazel.de> wrote:

> Hi,
>
> I had missed David's original email on this topic...
>
> On 2022-07-14 18:58:09 -0400, Bruce Momjian wrote:
> > On Wed, Apr 20, 2022 at 04:40:44PM -0700, David G. Johnston wrote:
> > > The new cumulative stats subsystem no longer has a "lost under heavy
> load"
> > > problem so that parenthetical should go (or at least be modified).
> > >
> > > These stats can be reset so some discussion about how the system uses
> them
> > > given that possibility seems like it would be good to add here.  I'm
> not sure
> > > what that should look like though.
> > >
> > > diff --git a/doc/src/sgml/maintenance.sgml
> b/doc/src/sgml/maintenance.sgml
> > > index 04a04e0e5f..360807c8f9 100644
> > > --- a/doc/src/sgml/maintenance.sgml
> > > +++ b/doc/src/sgml/maintenance.sgml
> > > @@ -652,9 +652,8 @@ vacuum insert threshold = vacuum base insert
> threshold +
> > > vacuum insert scale fac
> > >      tuples to be frozen by earlier vacuums.  The number of obsolete
> tuples and
> > >      the number of inserted tuples are obtained from the cumulative
> statistics
> > > system;
> > >      it is a semi-accurate count updated by each
> <command>UPDATE</command>,
> > > -    <command>DELETE</command> and <command>INSERT</command>
> operation.  (It is
> > > -    only semi-accurate because some information might be lost under
> heavy
> > > -    load.)  If the <structfield>relfrozenxid</structfield> value of
> the table
> > > +    <command>DELETE</command> and <command>INSERT</command> operation.
> > > +    If the <structfield>relfrozenxid</structfield> value of the table
> > >      is more than <varname>vacuum_freeze_table_age</varname>
> transactions old,
> > >      an aggressive vacuum is performed to freeze old tuples and advance
> > >      <structfield>relfrozenxid</structfield>; otherwise, only pages
> that have
> > > been modified
> >
> > Yes, I agree and plan to apply this patch soon.
>
> It might make sense to still say semi-accurate, but adjust the explanation
> to
> say that stats reporting is not instantaneous?
>
>
Unless that delay manifests in executing an UPDATE in a session then
looking at these views in the same session and not seeing that update
reflected I wouldn't mention it.  Concurrency aspects are reasonably
expected here.  But if we do want to mention it maybe:

 "...it is an eventually-consistent count updated by..."

David J.

Reply via email to