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