Re: Unable to test parallel aggregate/joins in Postgres beta 2

From: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
To: "Madusudanan(dot)B(dot)N" <b(dot)n(dot)madusudanan(at)gmail(dot)com>
Cc: Haribabu Kommi <kommi(dot)haribabu(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Unable to test parallel aggregate/joins in Postgres beta 2
Date: 2016-07-15 02:17:42
Message-ID: CAA4eK1Lhy=ybxHuveArSEn4Fc5Yrn3WwQah9K5q9J+M+TSF8hQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Etsuro Fujita 2016-07-15 02:37:51 Re: Oddity in handling of cached plans for FDW queries
Previous Message Michael Paquier 2016-07-14 23:38:19 Re: Issue in pg_catalog.pg_indexes view definition