Re: shared-memory based stats collector

From: Andres Freund <andres(at)anarazel(dot)de>
To: Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>
Cc: ibrar(dot)ahmad(at)gmail(dot)com, masao(dot)fujii(at)oss(dot)nttdata(dot)com, gkokolatos(at)protonmail(dot)com, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: shared-memory based stats collector
Date: 2022-03-03 02:16:00
Message-ID: 20220303021600.hs34ghqcw6zcokdh@alap3.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

On 2021-07-26 18:27:54 -0700, Andres Freund wrote:
> I had intended to post a rebase by now. But while I did mostly finish
> that (see [1]) I unfortunately encountered a new issue around
> partitioned tables, see [2]. Currently I'm hoping for a few thoughts on
> that thread about the best way to address the issues.

Now that https://postgr.es/m/20220125063131.4cmvsxbz2tdg6g65%40alap3.anarazel.de
is resolved, here's a rebased version. With a good bit of further cleanup.

One "big" thing that I'd like to figure out is a naming policy for the
different types prefixed with PgStat. We have different groups of types:

- "pending statistics", that are accumulated but not yet submitted to the
shared stats system, like PgStat_TableStatus, PgStat_BackendFunctionEntry
etc
- accumulated statistics like PgStat_StatDBEntry, PgStat_SLRUStats. About half are
prefixed with PgStat_Stat, the other just with PgStat_
- random other types like PgStat_Single_Reset_Type, ...

To me it's very confusing to have these all in an essentially undistinguishing
namespace, particularly the top two items.

I think we should at least do s/PgStat_Stat/PgStat_/. Perhaps we should use a
distinct PgStatPending_* for the pending item? I can't quite come up with a
good name for the "accumulated" ones.

I'd like that get resolved first because I think that'd allow commiting the
prepatory split and reordering patches.

Greetings,

Andres Freund

Attachment Content-Type Size
v65-0001-dshash-Add-sequential-scan-support.patch text/x-diff 9.3 KB
v65-0002-pgstat-Introduce-pgstat_relation_should_count.patch text/x-diff 10.4 KB
v65-0003-pgstat-xact-level-cleanups-consolidation.patch text/x-diff 6.0 KB
v65-0004-pgstat-Split-out-relation-database-stats-handlin.patch text/x-diff 6.0 KB
v65-0005-pgstat-Split-different-types-of-stats-into-separ.patch text/x-diff 124.4 KB
v65-0006-pgstat-reorder-file-pgstat.c-pgstat.h-contents.patch text/x-diff 43.1 KB
v65-0007-pgstat-Add-pgstat_copy_relation_stats.patch text/x-diff 3.5 KB
v65-0008-pgstat-store-statistics-in-shared-memory.patch text/x-diff 382.6 KB
v65-0009-pgstat-Extend-pgstat-test-coverage.patch text/x-diff 87.2 KB
v65-0010-pgstat-Move-pgstat.c-to-utils-activity.patch text/x-diff 1.9 KB
v65-0011-pgstat-Rename-STATS_COLLECTOR-GUC-group-to-STATS.patch text/x-diff 3.8 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2022-03-03 02:21:06 Re: Design of pg_stat_subscription_workers vs pgstats
Previous Message Pavel Stehule 2022-03-03 01:35:02 Re: [Proposal] Global temporary tables