From: | "Zhijie Hou (Fujitsu)" <houzj(dot)fnst(at)fujitsu(dot)com> |
---|---|
To: | shveta malik <shveta(dot)malik(at)gmail(dot)com>, Peter Smith <smithpb2250(at)gmail(dot)com> |
Cc: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Nisha Moond <nisha(dot)moond412(at)gmail(dot)com>, "Hayato Kuroda (Fujitsu)" <kuroda(dot)hayato(at)fujitsu(dot)com> |
Subject: | RE: Collect statistics about conflicts in logical replication |
Date: | 2024-08-30 06:45:41 |
Message-ID: | OS0PR01MB571654F93F1CAB57E9662FCA94972@OS0PR01MB5716.jpnprd01.prod.outlook.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Friday, August 30, 2024 2:24 PM shveta malik <shveta(dot)malik(at)gmail(dot)com> wrote:
>
> On Fri, Aug 30, 2024 at 10:53 AM Peter Smith <smithpb2250(at)gmail(dot)com>
> wrote:
> >
> > Hi Hou-San. Here are my review comments for v4-0001.
Thanks Shveta and Peter for giving comments !
> >
> > ======
> >
> > 1. Add links in the docs
> >
> > IMO it would be good for all these confl_* descriptions (in
> > doc/src/sgml/monitoring.sgml) to include links back to where each of
> > those conflict types was defined [1].
> >
> > Indeed, when links are included to the original conflict type
> > information then I think you should remove mentioning
> > "track_commit_timestamp":
> > + counted only when the
> > + <link
> linkend="guc-track-commit-timestamp"><varname>track_commit_timesta
> mp</varname></link>
> > + option is enabled on the subscriber.
> >
> > It should be obvious that you cannot count a conflict if the conflict
> > does not happen, but I don't think we should scatter/duplicate those
> > rules in different places saying when certain conflicts can/can't
> > happen -- we should just link everywhere back to the original
> > description for those rules.
>
> +1, will make the doc better.
Changed. To add link to each conflict type, I added "<varlistentry
id="conflict-xx, xreflabel=xx" to each conflict in logical-replication.sgml.
>
> > ~~~
> >
> > 2. Arrange all the counts into an intuitive/natural order
> >
> > There is an intuitive/natural ordering for these counts. For example,
> > the 'confl_*' count fields are in the order insert -> update ->
> > delete, which LGTM.
> >
> > Meanwhile, the 'apply_error_count' and the 'sync_error_count' are not
> > in a good order.
> >
> > IMO it makes more sense if everything is ordered as:
> > 'sync_error_count', then 'apply_error_count', then all the 'confl_*'
> > counts.
> >
> > This comment applies to lots of places, e.g.:
> > - docs (doc/src/sgml/monitoring.sgml)
> > - function pg_stat_get_subscription_stats (pg_proc.dat)
> > - view pg_stat_subscription_stats
> > (src/backend/catalog/system_views.sql)
> > - TAP test SELECTs (test/subscription/t/026_stats.pl)
> >
> > As all those places are already impacted by this patch, I think it
> > would be good if (in passing) we (if possible) also swapped the
> > sync/apply counts so everything is ordered intuitively top-to-bottom
> > or left-to-right.
>
> Not sure about this though. It does not seem to belong to the current patch.
I also don't think we should handle that in this patch.
Here is V5 patch which addressed above and Shveta's[1] comments.
Best Regards,
Hou zj
Attachment | Content-Type | Size |
---|---|---|
v5-0001-Collect-statistics-about-conflicts-in-logical-rep.patch | application/octet-stream | 27.9 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | torikoshia | 2024-08-30 06:45:55 | Re: ANALYZE ONLY |
Previous Message | Amit Kapila | 2024-08-30 06:42:56 | Re: Conflict Detection and Resolution |