Re: Add pg_stat_kind_info system view

From: Sami Imseih <samimseih(at)gmail(dot)com>
To: Michael Paquier <michael(at)paquier(dot)xyz>
Cc: Bertrand Drouvot <bertranddrouvot(dot)pg(at)gmail(dot)com>, Tristan Partin <tristan(at)partin(dot)io>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Add pg_stat_kind_info system view
Date: 2026-06-30 22:36:57
Message-ID: CAA5RZ0u3uGasPEVF1n9HBamq=m7SY_HL6MREycT2Wt1DfAg6wA@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

Thanks for working on this. I like this overall, but have some comments.

1/

+ One row for each loaded statistics kind, showing metadata
about the kind.

The description says "showing metadata about the kind" but
the count column returns live runtime data (via pgstat_get_entry_count()),
not just metadata. The description should acknowledge both.

2/

+ <structfield>shared_size</structfield> <type>bigint</type>
+ </para>
+ <para>
+ Size in bytes of a shared memory entry for this statistics kind.
+ <literal>NULL</literal> for built-in fixed-amount kinds, whose
+ single entry lives in a statically-allocated slot rather than a
+ sized shared memory entry.

I think we should just use info->shared_data_len for both fixed and
variable-length kinds. This shows the entry_size which is what an
extension developer will care about. Even info->shared_size for
variable-length kinds does not include the per-entry overhead,
so info->shared_data_len will be useful to understand if the size
of your entry changed after an upgrade, etc. Also, we should
rename it to "entry_size" instead of "shared_size"

3/

+ <structfield>count</structfield> <type>bigint</type>
+ </para>
+ <para>
+ Number of tracked entries for this kind. For fixed-amount
kinds, this is
+ always 1. For variable-numbered kinds, this is the number of objects
+ currently tracked. <literal>NULL</literal> if the kind does not track
+ entry counts.
+ </para>
+ </entry>

I think this should be 0 for all kinds by default. Only ever > 0 for
variable-numbered
kinds with entry tracking enabled. No NULLs. The fields should be called
"entry_count" instead of "count". We should update the documentation to
reflect that as well. That seems easier to query than having mixed NULLs and
numbers.

Sami Imseih
Amazon Web Services (AWS)

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message surya poondla 2026-06-30 23:03:14 Re: Handle concurrent drop when doing whole database vacuum
Previous Message Zsolt Parragi 2026-06-30 22:19:32 Re: proposal - queryid can be used as filter for auto_explain