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

Поиск
Список
Период
Сортировка
От Andres Freund
Тема Re: Naming of the different stats systems / "stats collector"
Дата
Msg-id 20220309023235.qqxqgofjuvd32yei@alap3.anarazel.de
обсуждение исходный текст
Ответ на Re: Naming of the different stats systems / "stats collector"  ("David G. Johnston" <david.g.johnston@gmail.com>)
Ответы Re: Naming of the different stats systems / "stats collector"
Список 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@anarazel.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@anarazel.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



В списке pgsql-hackers по дате отправления:

Предыдущее
От: "wangw.fnst@fujitsu.com"
Дата:
Сообщение: RE: Logical replication timeout problem
Следующее
От: "Imseih (AWS), Sami"
Дата:
Сообщение: Re: Add index scan progress to pg_stat_progress_vacuum