|From:||Dilip Kumar <dilipbalaut(at)gmail(dot)com>|
|To:||Robert Haas <robertmhaas(at)gmail(dot)com>|
|Subject:||Re: Proposal : Parallel Merge Join|
|Views:||Raw Message | Whole Thread | Download mbox|
On Tue, Dec 13, 2016 at 8:34 PM, Dilip Kumar <dilipbalaut(at)gmail(dot)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
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
I have observed that with query3, we are getting linear scalability
('explain analyze' results are attached).
TPCH 300 scale factor
work_mem = 1GB
shared_buffer = 1GB
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
* I have also verified reading on the head, without modifying
random_page_cost=seq_page_cost, but there is no change in plan or
* I have tried to increase the max_parallel_workers_per_gather to 8
but I did not observe further scaling.
|Next Message||Robert Haas||2016-12-21 04:41:57||Re: pgstattuple documentation clarification|
|Previous Message||Amit Kapila||2016-12-21 04:32:54||Re: Hang in pldebugger after git commit : 98a64d0|