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