On Thu, Aug 17, 2017 at 8:08 PM, Amit Kapila <amit.kapil...@gmail.com> wrote: > On Thu, Aug 17, 2017 at 7:49 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: >> Amit Kapila <amit.kapil...@gmail.com> writes: >>> On Tue, Aug 15, 2017 at 7:16 PM, Tom Lane <t...@sss.pgh.pa.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
execrescan_gathermerge_v3.patch
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