On Tue, Dec 13, 2016 at 8:34 PM, Dilip Kumar <dilipbal...@gmail.com> wrote: > I have created two patches as per the suggestion. > > 1. mergejoin_refactoring_v2.patch --> Move functionality of > considering various merge join path into new function. > 2. parallel_mergejoin_v2.patch -> This adds the functionality of > supporting partial mergejoin paths. This will apply on top of > mergejoin_refactoring_v2.patch.
We have done further analysis of the performance with TPCH benchmark
at higher scale factor. I have tested parallel merge join patch along
with parallel index scan[1]
I have observed that with query3, we are getting linear scalability
('explain analyze' results are attached).
Test Setup:
---------------
TPCH 300 scale factor
work_mem = 1GB
shared_buffer = 1GB
random_page_cost=seq_page_cost=0.1
max_parallel_workers_per_gather=4 (warm cache ensured)
The median of 3 runs (reading are quite stable).
On Head: 2702568.099 ms
With Patch: 547363.164 ms
Other Experiments:
* I have also verified reading on the head, without modifying
random_page_cost=seq_page_cost, but there is no change in plan or
execution time.
* I have tried to increase the max_parallel_workers_per_gather to 8
but I did not observe further scaling.
[1]
https://www.postgresql.org/message-id/CAA4eK1KA4LwTYXZG%3Dk3J2bA%2BZOEYnz2gkyWBKgY%3D_q0xJRBMDw%40mail.gmail.com
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
3_head.out
Description: Binary data
3_patch.out
Description: Binary data
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
