Movatterモバイル変換


[0]ホーム

URL:


Quick Links

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:Whole Thread |Raw Message |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 thathttps://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

AttachmentContent-TypeSize
v65-0001-dshash-Add-sequential-scan-support.patchtext/x-diff9.3 KB
v65-0002-pgstat-Introduce-pgstat_relation_should_count.patchtext/x-diff10.4 KB
v65-0003-pgstat-xact-level-cleanups-consolidation.patchtext/x-diff6.0 KB
v65-0004-pgstat-Split-out-relation-database-stats-handlin.patchtext/x-diff6.0 KB
v65-0005-pgstat-Split-different-types-of-stats-into-separ.patchtext/x-diff124.4 KB
v65-0006-pgstat-reorder-file-pgstat.c-pgstat.h-contents.patchtext/x-diff43.1 KB
v65-0007-pgstat-Add-pgstat_copy_relation_stats.patchtext/x-diff3.5 KB
v65-0008-pgstat-store-statistics-in-shared-memory.patchtext/x-diff382.6 KB
v65-0009-pgstat-Extend-pgstat-test-coverage.patchtext/x-diff87.2 KB
v65-0010-pgstat-Move-pgstat.c-to-utils-activity.patchtext/x-diff1.9 KB
v65-0011-pgstat-Rename-STATS_COLLECTOR-GUC-group-to-STATS.patchtext/x-diff3.8 KB

In response to

Responses

Browse pgsql-hackers by date

 FromDateSubject
Next MessageAndres Freund2022-03-03 02:21:06Re: Design of pg_stat_subscription_workers vs pgstats
Previous MessagePavel Stehule2022-03-03 01:35:02Re: [Proposal] Global temporary tables

[8]ページ先頭

©2009-2026 Movatter.jp