| 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)
| 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 |