Re: Collect statistics about conflicts in logical replication

On Thu, Aug 29, 2024 at 4:59 AM Peter Smith <smithpb2250(at)gmail(dot)com> wrote:
>
> On Wed, Aug 28, 2024 at 9:19 PM Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
> >
> > On Wed, Aug 28, 2024 at 11:43 AM shveta malik <shveta(dot)malik(at)gmail(dot)com> wrote:
> > >
> > > Thanks for the patch. Just thinking out loud, since we have names like
> > > 'apply_error_count', 'sync_error_count' which tells that they are
> > > actually error-count, will it be better to have something similar in
> > > conflict-count cases, like 'insert_exists_conflict_count',
> > > 'delete_missing_conflict_count' and so on. Thoughts?
> > >
> >
> > It would be better to have conflict in the names but OTOH it will make
> > the names a bit longer. The other alternatives could be (a)
> > insert_exists_confl_count, etc. (b) confl_insert_exists_count, etc.
> > (c) confl_insert_exists, etc. These are based on the column names in
> > the existing view pg_stat_database_conflicts [1]. The (c) looks better
> > than other options but it will make the conflict-related columns
> > different from error-related columns.
> >
> > Yet another option is to have a different view like
> > pg_stat_subscription_conflicts but that sounds like going too far.

Yes, I think we are good with pg_stat_subscription_stats for the time being.

> >
> > [1] - https://www.postgresql.org/docs/devel/monitoring-stats.html#MONITORING-PG-STAT-DATABASE-CONFLICTS-VIEW
>
> Option (c) looked good to me.

+1 for option c. it should be okay to not have '_count' in the name.

> Removing the suffix "_count" is OK. For example, try searching all of
> Chapter 27 ("The Cumulative Statistics System") [1] for columns
> described as "Number of ..." and you will find that a "_count" suffix
> is used only rarely.
>
> Adding the prefix "confl_" is OK. As mentioned, there is a precedent
> for this. See "pg_stat_database_conflicts" [2].
>
> Mixing column names where some have and some do not have "_count"
> suffixes may not be ideal, but I see no problem because there are
> precedents for that too. E.g. see "pg_stat_replication_slots" [3], and
> "pg_stat_all_tables" [4].
>
> ======
> [1] https://www.postgresql.org/docs/devel/monitoring-stats.html
> [2] https://www.postgresql.org/docs/devel/monitoring-stats.html#MONITORING-PG-STAT-DATABASE-CONFLICTS-VIEW
> [3] https://www.postgresql.org/docs/devel/monitoring-stats.html#MONITORING-PG-STAT-REPLICATION-SLOTS-VIEW
> [4] https://www.postgresql.org/docs/devel/monitoring-stats.html#MONITORING-PG-STAT-ALL-TABLES-VIEW
>
> Kind Regards,
> Peter Smith.
> Fujitsu Australia