Re: Proposal : Parallel Merge Join
Dilip Kumar <dilipbalaut@gmail.com>
From: Dilip Kumar <dilipbalaut@gmail.com>
To: Robert Haas <robertmhaas@gmail.com>
Cc: pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2016-12-21T04:35:14Z
Lists: pgsql-hackers
Attachments
- 3_head.out (application/octet-stream)
- 3_patch.out (application/octet-stream)
On Tue, Dec 13, 2016 at 8:34 PM, Dilip Kumar <dilipbalaut@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
Commits
-
Consider parallel merge joins.
- 3bc7dafa9beb 10.0 landed
-
Preparatory refactoring for parallel merge join support.
- a71f10189dc1 10.0 landed
-
Fix parallel hash join path search.
- 655393a022bd 10.0 landed