Re: postgres_fdw: commit remote (sub)transactions in parallel during pre-commit
От | David Zhang |
---|---|
Тема | Re: postgres_fdw: commit remote (sub)transactions in parallel during pre-commit |
Дата | |
Msg-id | 046f54b1-cdb7-88fb-5287-c48628092ca1@highgo.ca обсуждение исходный текст |
Ответ на | postgres_fdw: commit remote (sub)transactions in parallel during pre-commit (Etsuro Fujita <etsuro.fujita@gmail.com>) |
Ответы |
Re: postgres_fdw: commit remote (sub)transactions in parallel during pre-commit
|
Список | pgsql-hackers |
> 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
В списке pgsql-hackers по дате отправления: