RE: Resetting spilled txn statistics in pg_stat_replication

From: "Shinoda, Noriyoshi (PN Japan A&PS Delivery)" <noriyoshi(dot)shinoda(at)hpe(dot)com>
To: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, Masahiko Sawada <masahiko(dot)sawada(at)2ndquadrant(dot)com>
Cc: Dilip Kumar <dilipbalaut(at)gmail(dot)com>, Magnus Hagander <magnus(at)hagander(dot)net>, Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Ajin Cherian <itsajin(at)gmail(dot)com>
Subject: RE: Resetting spilled txn statistics in pg_stat_replication
Date: 2020-10-19 00:29:05
Message-ID: TU4PR8401MB115225EC363982C65A3E1526EE1E0@TU4PR8401MB1152.NAMPRD84.PROD.OUTLOOK.COM
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Amit-san, Sawada-san,

Thank you for your comment.

> AFAICS, we use name data-type in many other similar stats views like pg_stat_subscription, pg_statio_all_sequences, pg_stat_user_functions,
> pg_stat_all_tables. So, shouldn't we consistent with those views?

I checked the data type used for the statistics view identity column. 'Name' type columns are used in many views. If there is no problem with PostgreSQL standard, I would like to change both the data type and the column name.

- name type
pg_stat_activity.datname
pg_stat_replication.usename
pg_stat_subscription.subname
pg_stat_database.datname
pg_stat_database_conflicts.datname
pg_stat_all_tables.schemaname/.relname
pg_stat_all_indexes.schemaname/.relname/.indexrelname
pg_statio_all_tables.schemaname/.relname
pg_statio_all_indexes.schemaname/.relname/.indexname
pg_statio_all_sequences.schemaname/.relname
pg_stat_user_functions.schemaname/.funcname

- text type
pg_stat_replication_slots.name
pg_stat_slru.name
pg_backend_memory_contexts.name

The attached patch makes the following changes.
- column name: name to slot_name
- data type: text to name
- macro: ... CLOS to ... COLS

Regards,
Noriyoshi Shinoda

-----Original Message-----
From: Amit Kapila [mailto:amit(dot)kapila16(at)gmail(dot)com]
Sent: Thursday, October 15, 2020 5:52 PM
To: Masahiko Sawada <masahiko(dot)sawada(at)2ndquadrant(dot)com>
Cc: Shinoda, Noriyoshi (PN Japan A&PS Delivery) <noriyoshi(dot)shinoda(at)hpe(dot)com>; Dilip Kumar <dilipbalaut(at)gmail(dot)com>; Magnus Hagander <magnus(at)hagander(dot)net>; Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>; PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>; Ajin Cherian <itsajin(at)gmail(dot)com>
Subject: Re: Resetting spilled txn statistics in pg_stat_replication

On Tue, Oct 13, 2020 at 5:41 AM Masahiko Sawada <masahiko(dot)sawada(at)2ndquadrant(dot)com> wrote:
>
> On Mon, 12 Oct 2020 at 23:45, Shinoda, Noriyoshi (PN Japan A&PS
> Delivery) <noriyoshi(dot)shinoda(at)hpe(dot)com> wrote:
> >
> >
> > > As it may have been discussed, I think the 'name' column in pg_stat_replication_slots is more consistent with the column name and data type matched to the pg_replication_slots catalog.
> > > The attached patch changes the name and data type of the 'name' column to slot_name and 'name' type, respectively.
> >
> > It seems a good idea to me. In other system views, we use the name data type for object name. When I wrote the first patch, I borrowed the code for pg_stat_slru which uses text data for the name but I think it's an oversight.
>
> Hmm, my above observation is wrong. All other statistics use text data
> type and internally use char[NAMEDATALEN].
>

AFAICS, we use name data-type in many other similar stats views like pg_stat_subscription, pg_statio_all_sequences, pg_stat_user_functions, pg_stat_all_tables. So, shouldn't we consistent with those views?

--
With Regards,
Amit Kapila.

Attachment Content-Type Size
pg_stat_replication_slots_v4.patch application/octet-stream 5.7 KB

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2020-10-19 01:08:58 Re: Possible memory leak in pgcrypto with EVP_MD_CTX
Previous Message David Rowley 2020-10-19 00:18:43 Re: Assertion failure with LEFT JOINs among >500 relations