Re: shared-memory based stats collector - v70 - Mailing list pgsql-hackers

From Andres Freund
Subject Re: shared-memory based stats collector - v70
Date
Msg-id 20220406192734.7hhspfpepcq2cyum@alap3.anarazel.de
Whole thread Raw
In response to Re: shared-memory based stats collector - v70  (Lukas Fittl <lukas@fittl.com>)
Responses Re: shared-memory based stats collector - v70  (Justin Pryzby <pryzby@telsasoft.com>)
List pgsql-hackers
Hi,

On 2022-04-06 12:14:35 -0700, Lukas Fittl wrote:
> On Tue, Apr 5, 2022 at 8:00 PM Andres Freund <andres@anarazel.de> wrote:
> 
> > Here comes v70:
> >
> 
> Some small nitpicks on the docs:

Thanks!

> > From 13090823fc4c7fb94512110fb4d1b3e86fb312db Mon Sep 17 00:00:00 2001
> > From: Andres Freund <andres@anarazel.de>
> > Date: Sat, 2 Apr 2022 19:38:01 -0700
> > Subject: [PATCH v70 14/27] pgstat: update docs.
> > ...
> > diff --git a/doc/src/sgml/config.sgml b/doc/src/sgml/config.sgml
> > -      These parameters control server-wide statistics collection
> features.
> > -      When statistics collection is enabled, the data that is produced
> can be
> > +      These parameters control server-wide cumulative statistics system.
> > +      When enabled, the data that is collected can be
> 
> Missing "the" ("These parameters control the server-wide cumulative
> statistics system").

> > diff --git a/doc/src/sgml/monitoring.sgml b/doc/src/sgml/monitoring.sgml
> > +   any of the accumulated statistics, acessed values are cached until
> the end
> 
> "acessed" => "accessed"

> > +   <varname>stats_fetch_consistency</varname> can be set
> > +   <literal>snapshot</literal>, at the price of increased memory usage
> for
> 
> Missing "to" ("can be set to <literal>snapshot</literal>")

Fixed.

> > +   caching not-needed statistics data.  Conversely, if it's known that
> statistics
> 
> Double space between "data." and "Conversely" (not sure if that matters)
> > +   current transaction's statistics snapshot or cached values (if any).
> The
> 
> Double space between "(if any)." and "The" (not sure if that matters)

That's done pretty widely in the docs and comments.


> > +   next use of statistical information will cause a new snapshot to be
> built
> > +   or accessed statistics to be cached.
> 
> I believe this should be an "and", not an "or". (next access builds both a
> new snapshot and caches accessed statistics)

I *think* or is correct? The new snapshot is when stats_fetch_consistency =
snapshot, the cached is when stats_fetch_consistency = cache. Not sure how to
make that clearer without making it a lot longer. Suggestions?

Greetings,

Andres Freund



pgsql-hackers by date:

Previous
From: Stephen Frost
Date:
Subject: Re: Kerberos delegation support in libpq and postgres_fdw
Next
From: Stephen Frost
Date:
Subject: Re: Postgres restart in the middle of exclusive backup and the presence of backup_label file