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
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. |