Re: Naming of the different stats systems / "stats collector"

From: Andres Freund <andres(at)anarazel(dot)de>
To: "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>
Cc: Pg Hackers <pgsql-hackers(at)postgresql(dot)org>, Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>
Subject: Re: Naming of the different stats systems / "stats collector"
Date: 2022-03-09 02:32:35
Message-ID: 20220309023235.qqxqgofjuvd32yei@alap3.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

On 2022-03-08 19:13:45 -0700, David G. Johnston wrote:
> On Tue, Mar 8, 2022 at 6:50 PM Andres Freund <andres(at)anarazel(dot)de> wrote:
>
> > On 2022-03-08 15:55:04 -0700, David G. Johnston wrote:
> > > On Tue, Mar 8, 2022 at 1:54 PM Andres Freund <andres(at)anarazel(dot)de> wrote:
> > > > One thing I'm not yet happy around the shared memory stats patch is
> > > > naming. Currently a lot of comments say things like:
> > > >
> > > > * [...] We convert to
> > > > * microseconds in PgStat_Counter format when transmitting to the
> > > > collector.
> > > >
> >
>
> "...format for writing to the statistics datastore"

That could also describe pg_statistic. Nor are we writing during normal
operation (stats are first accumulated locally and subsequently a shared
memory hash table is updated), the on-disk file is only written at shutdown.

Which is my problem with this - we need a descriptive term / shorthand that
describes the type of statistics we currently send to the stats collector.

"cumulative stats subsystem"?

> > > > /* ----------
> > > > * pgstat_report_subscription_drop() -
> > > > *
> > > > * Tell the collector about dropping the subscription.
> > > > * ----------
> > > > */
> >
>
> I would expect that either the function gets renamed or just goes away.
> Just changing the word "collector" isn't going to be a good change, the new
> description should describe whatever the new behavior is.

It currently has the same signature in the patch, and I don't forsee that
changing.

> As the process goes away we are now dealing directly with a conceptual
> datastore. And instead of referring to the implementation detail of how
> statistics are collected we can just refer to the "collection" behavior
> generically. Whether we funnel through a process or write directly to the
> datastore it is still statistics collection.

We have many other types of stats that we collect, so yes, it's statistic
collection, but that's not descriptive enough imo. "Stats collector" somewhat
worked because the fact that the collector process was involved served to
distinguish from other types of stats.

Greetings,

Andres Freund

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Imseih (AWS), Sami 2022-03-09 02:35:31 Re: Add index scan progress to pg_stat_progress_vacuum
Previous Message wangw.fnst@fujitsu.com 2022-03-09 02:27:35 RE: Logical replication timeout problem