On Thu, Jul 14, 2016 at 7:22 PM, Madusudanan.B.N
<b.n.madusudanan@gmail.com> wrote:
>
>
> On Thu, Jul 14, 2016 at 7:09 PM, Haribabu Kommi <kommi.haribabu@gmail.com>
> wrote:
>>
>> On Thu, Jul 14, 2016 at 11:16 PM, Madusudanan.B.N
>> <b.n.madusudanan@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