From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Amit Khandekar <amitdkhan(dot)pg(at)gmail(dot)com> |
Cc: | Ashutosh Bapat <ashutosh(dot)bapat(at)enterprisedb(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Parallel Append implementation |
Date: | 2017-03-13 11:46:41 |
Message-ID: | CA+TgmoavGCkA1eV-DKX3te+CtCF-C4-CrYmU=fGihsj_ar6myQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, Mar 13, 2017 at 4:59 AM, Amit Khandekar <amitdkhan(dot)pg(at)gmail(dot)com> wrote:
> I agree that we should preferably have the non-partial plans started
> first. But I am not sure if it is really worth ordering the partial
> plans by cost. The reason we ended up not keeping track of the
> per-subplan parallel_worker, is because it would not matter much ,
> and we would just equally distribute the workers among all regardless
> of how big the subplans are. Even if smaller plans get more worker,
> they will finish faster, and workers would be available to larger
> subplans sooner.
Imagine that the plan costs are 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, and 10
and you have 2 workers.
If you move that 10 to the front, this will finish in 10 time units.
If you leave it at the end, it will take 15 time units.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | Rafia Sabih | 2017-03-13 12:18:54 | Re: Enabling parallelism for queries coming from SQL or other PL functions |
Previous Message | Magnus Hagander | 2017-03-13 11:11:30 | Re: Typo in snapbuild.c |