On Thu, Jul 14, 2016 at 7:22 PM, Madusudanan.B.N <b.n.madusuda...@gmail.com> wrote: > > > On Thu, Jul 14, 2016 at 7:09 PM, Haribabu Kommi <kommi.harib...@gmail.com> > wrote: >> >> On Thu, Jul 14, 2016 at 11:16 PM, Madusudanan.B.N >> <b.n.madusuda...@gmail.com> wrote: >> > >> > 3) Is there any kind of toggle to enable parallel aggregate/join feature >> > ? >> > >> >> I am able to generate parallel plan, The parallel plan may be costly >> in your query compared >> to other scans, because of which it is not selecting the parallel plan. >> >> It is possible that if the table size is very small or you are >> selecting all records of the table >> and etc. >> >> postgres=# insert into test values(generate_series(1,1000000), 'Test'); >> INSERT 0 1000000 >> postgres=# explain select * from test where f1 < 9900; >> QUERY PLAN >> >> ----------------------------------------------------------------------------- >> Gather (cost=1000.00..23719.93 rows=188964 width=105) >> Workers Planned: 2 >> -> Parallel Seq Scan on test (cost=0.00..22719.93 rows=78735 >> width=105) >> Filter: (f1 < 9900) >> (4 rows) > > > For the above example, I can see that it does choose parallel plan. However > as said above, for other cases it does not choose a parallel plan. > > Is there any other considerations apart from the mentioned ones on why pg > would not choose a parallel plan ? >
You can try by setting parallel_setup_cost=0 and parallel_tuple_cost=0, though changing that way is not advisable. If that doesn't work for you, share the exact test for which you are expecting parallel plan to be selected. -- With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
