On Thu, May 5, 2022 at 6:39 AM David Zhang <david.zh...@highgo.ca> wrote: > On 2022-05-02 1:25 a.m., Etsuro Fujita wrote: > > On Wed, Apr 20, 2022 at 4:55 AM David Zhang <david.zh...@highgo.ca> wrote: > >> I tried to apply the patch to master and plan to run some tests, but got > >> below errors due to other commits. > > I rebased the patch against HEAD. Attached is an updated patch. > > Applied the patch v8 to master branch today, and the `make check` is OK. > I also repeated previous performance tests on three virtual Ubuntu > 18.04, and the performance improvement of parallel abort in 10 times > average is more consistent. > > before: > > abort.1 = 2.6344 ms > abort.2 = 4.2799 ms > > after: > > abort.1 = 1.4105 ms > abort.2 = 2.2075 ms
Good to know! Thanks for testing!
> >> + * remote server in parallel at (sub)transaction end.
> >>
> >> Here, I think the comment above could potentially apply to multiple
> >> remote server(s).
> > I agree on that point, but I think it's correct to say "the remote
> > server" here, because we determine this for the given remote server.
> > Maybe I'm missing something, so could you elaborate on it?
> Your understanding is correct. I was thinking `remote server(s)` would
> be easy for end user to understand but this is a comment in source code,
> so either way is fine for me.
Ok, but I noticed that the comment failed to mention that the
parallel_commit option is disabled by default. Also, I noticed a
comment above it:
* It's enough to determine this only when making new connection because
* all the connections to the foreign server whose keep_connections option
* is changed will be closed and re-made later.
This would apply to the parallel_commit option as well. How about
updating these like the attached? (I simplified the latter comment
and moved it to a more appropriate place.)
Best regards,
Etsuro Fujita
update-comment-in-make_new_connection.patch
Description: Binary data
