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