Re: Parallel seq. plan is not coming against inheritance or partition table

From: Ashutosh Sharma <ashu(dot)coek88(at)gmail(dot)com>
To: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, tushar <tushar(dot)ahuja(at)enterprisedb(dot)com>
Subject: Re: Parallel seq. plan is not coming against inheritance or partition table
Date: 2017-03-06 05:09:18
Message-ID: CAE9k0P=zuNHeLCrh5K0R0Hm23q4OaKO5OH6VuFmsOGPaXkj4ww@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

>
> Right, but OTOH, if we assign parallel workers by default, then it is
> quite possible that it would result in much worse plans. Consider a
> case where partition hierarchy has 1000 partitions and only one of
> them is big enough to allow parallel workers. Now in this case, with
> your proposed fix it will try to scan all the partitions in parallel
> workers which I think can easily result in bad performance.

Right. But, there can also be a case where 999 partitions are large
and eligible for PSS. In such case as well, PSS won't be selected.

I think
> the right way to make such plans parallel is by using Parallel Append
> node (https://commitfest.postgresql.org/13/987/). Alternatively, if
> you want to force parallelism in cases like the one you have shown in
> example, you can use Alter Table .. Set (parallel_workers = 1).

Okay, I was not aware of Parallel Append. Thanks.

With Regards,
Ashutosh Sharma
EnterpriseDB: http://www.enterprisedb.com

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Simon Riggs 2017-03-06 05:25:18 Re: dropping partitioned tables without CASCADE
Previous Message Ashutosh Bapat 2017-03-06 04:32:17 Re: Print correct startup cost for the group aggregate.