> I evaluated the effectiveness of the patch using a simple
> multi-statement transaction:
>
> BEGIN;
> SAVEPOINT s;
> INSERT INTO ft1 VALUES (10, 10);
> INSERT INTO ft2 VALUES (20, 20);
> RELEASE SAVEPOINT s;
> COMMIT;
>
> where ft1 and ft2 are foreign tables created on different foreign
> servers hosted on different machines. I ran the transaction five
> times using the patch with the option enabled/disabled, and measured
> the latencies for the RELEASE and COMMIT commands in each run. The
> average latencies for these commands over the five runs are:
>
> * RELEASE
> parallel_commit=0: 0.385 ms
> parallel_commit=1: 0.221 ms
>
> * COMMIT
> parallel_commit=0: 1.660 ms
> parallel_commit=1: 0.861 ms
>
> With the option enabled, the average latencies for both commands are
> reduced significantly!
Followed your instructions, I performed some basic tests to compare the
performance between before and after. In my testing environment (two
foreign servers on the same local machine), the performance varies,
sometimes the time spent on RELEASE and COMMIT without patch are close
to after patched, but seems it always perform better after patched. Then
I ran a 1-millions tuples insert, 5 times average is something like below,
Before
RELEASE 0.171 ms, COMMIT 1.861 ms
After
RELEASE 0.147 ms, COMMIT 1.305 ms
Best regards,
--
David
Software Engineer
Highgo Software Inc. (Canada)
www.highgo.ca