Re: postgres_fdw: commit remote (sub)transactions in parallel during pre-commit

Applied patches v6-0002 and v6-0003 to master branch, and the `make 
check` test is ok.

Here is my test result in 10 times average on 3 virtual machines:
before the patches:

    abort.1 = 2.5473 ms

    abort.2 = 4.1572 ms

after the patches with OPTIONS (ADD parallel_abort 'true'):

    abort.1 = 1.7136 ms

    abort.2 = 2.5833 ms

Overall, it has about 32 ~ 37 % improvement in my testing environment.

On 2022-03-05 2:32 a.m., Etsuro Fujita wrote:
> On Mon, Feb 28, 2022 at 6:53 PM Etsuro Fujita<etsuro.fujita@gmail.com>  wrote:
>> Here is an updated version.  I added to the 0003 patch a macro for
>> defining the milliseconds to wait, as proposed by David upthread.
> I modified the 0003 patch further: 1) I added to
> pgfdw_cancel_query_end/pgfdw_exec_cleanup_query_end the PQconsumeInput
> optimization that we have in do_sql_command_end, and 2) I
> added/tweaked comments a bit further.  Attached is an updated version.
>
> Like [1], I ran a simple performance test using the following transaction:
>
> BEGIN;
> SAVEPOINT s;
> INSERT INTO ft1 VALUES (10, 10);
> INSERT INTO ft2 VALUES (20, 20);
> ROLLBACK TO SAVEPOINT s;
> RELEASE SAVEPOINT s;
> INSERT INTO ft1 VALUES (10, 10);
> INSERT INTO ft2 VALUES (20, 20);
> ABORT;
>
> where ft1 is a foreign table created on a foreign server hosted on the
> same machine as the local server, and ft2 is a foreign table created
> on a foreign server hosted on a different machine.  (In this test I
> used two machines, while in [1] I used three machines: one for the
> local server and the others for ft1 and ft2.)  The average latencies
> for the ROLLBACK TO SAVEPOINT and ABORT commands over ten runs of the
> above transaction with the parallel_abort option disabled/enabled are:
>
> * ROLLBACK TO SAVEPOINT
>    parallel_abort=0: 0.3217 ms
>    parallel_abort=1: 0.2396 ms
>
> * ABORT
>    parallel_abort=0: 0.4749 ms
>    parallel_abort=1: 0.3733 ms
>
> This option reduces the latency for ROLLBACK TO SAVEPOINT by 25.5
> percent, and the latency for ABORT by 21.4 percent.  From the results,
> I think the patch is useful.
>
> Best regards,
> Etsuro Fujita
>
> [1]https://www.postgresql.org/message-id/CAPmGK17dAZCXvwnfpr1eTfknTGdt%3DhYTV9405Gt5SqPOX8K84w%40mail.gmail.com
-- 
David

Software Engineer
Highgo Software Inc. (Canada)
www.highgo.ca