On Thu, Aug 17, 2017 at 8:08 PM, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
> On Thu, Aug 17, 2017 at 7:49 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> writes:
>>> On Tue, Aug 15, 2017 at 7:16 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>>> I should think it wouldn't be that expensive to create a test
>>>> case, if you already have test cases that invoke GatherMerge.
>>>> Adding a right join against a VALUES clause with a small number of
>>>> entries, and a non-mergeable/hashable join clause, ought to do it.
>>
>>> I have done some experiments based on this idea to generate a test,
>>> but I think it is not as straightforward as it appears.
>>
>> I did this (the first 4 SETs duplicate what's already used in
>> select_parallel.sql):
>>
>> regression=# set parallel_setup_cost=0;
>> SET
>> regression=# set parallel_tuple_cost=0;
>> SET
>> regression=# set min_parallel_table_scan_size=0;
>> SET
>> regression=# set max_parallel_workers_per_gather=4;
>> SET
>> regression=# set enable_hashagg TO 0;
>> SET
>> regression=# set enable_material TO 0;
>> SET
>> regression=# explain select * from (select string4, count((unique2))
>> from tenk1 group by string4 order by string4) ss right join
>> (values(1),(2)) v(x) on true;
>> QUERY PLAN
>> --------------------------------------------------------------------------------------------------
>> Nested Loop Left Join (cost=524.15..1086.77 rows=8 width=76)
>> -> Values Scan on "*VALUES*" (cost=0.00..0.03 rows=2 width=4)
>> -> Finalize GroupAggregate (cost=524.15..543.29 rows=4 width=72)
>> Group Key: tenk1.string4
>> -> Gather Merge (cost=524.15..543.17 rows=16 width=72)
>> Workers Planned: 4
>> -> Partial GroupAggregate (cost=524.10..542.89 rows=4 width=72)
>> Group Key: tenk1.string4
>> -> Sort (cost=524.10..530.35 rows=2500 width=68)
>> Sort Key: tenk1.string4
>> -> Parallel Seq Scan on tenk1 (cost=0.00..383.00 rows=2500 width=68)
>> (11 rows)
>>
>> regression=# select * from (select string4, count((unique2))
>> from tenk1 group by string4 order by string4) ss right join
>> (values(1),(2)) v(x) on true;
>> server closed the connection unexpectedly
>>
>>
>> So, not only is it not that hard to reach ExecReScanGatherMerge,
>> but there is indeed a bug to fix there somewhere. The stack
>> trace indicates that the failure occurs in a later execution
>> of ExecGatherMerge:
>>
>
> This will be fixed by the patch [1] (execrescan_gathermerge_v2.patch)
> I posted sometime back. The test case is slightly different, but may
> I can re post the patch with your test case.
>
I have kept the fix as it is but changed the test to match your test.
I think the another patch posted above to add a new guc for
enable_gather is still relevant and important.
--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com