On Wed, Mar 22, 2017 at 3:39 AM, Rushabh Lathia
wrote:
> Looking at the explain analyze output of both the plan, its clear that GM
> taking longer as its using external merge dist for the sort, where as
> another plan perform top-N heapsort. For normal sort path, it can consider
> the limit as bou
On Wed, Mar 22, 2017 at 1:09 PM, Rushabh Lathia
wrote:
> In the code, gather merge consider the limit for the sort into
> create_ordered_paths,
> which is wrong. Into create_ordered_paths(), GM should not consider the
> limit
> while doing costing for the sort node.
>
> Attached patch fix the bug.
Hi,
postgres=# explain analyze select * from test order by v1, v2 limit 10;
QUERY
PLAN
Limit (c
Thanks for reporting, I am looking into this.
On Wed, Mar 22, 2017 at 11:51 AM, Mithun Cy
wrote:
> Adding more rows to table make gather merge execution time very slow
> when compared to non-parallel plan we get after disabling gather
> merge.
>
> create table test as (select id, (random()*1
Adding more rows to table make gather merge execution time very slow
when compared to non-parallel plan we get after disabling gather
merge.
create table test as (select id, (random()*1)::int as v1, random() as
v2 from generate_series(1,1) id);
postgres=# set max_parallel_workers_per_
I accidently encountered a case where gather merge was picked as
default but disabling same by setting max_parallel_workers_per_gather
= 0; produced a non-parallel plan which was faster than gather merge,
but its cost is marked too high when compared to gather merge.
I guess we need some cost adju
