Re: [HACKERS] Increasing parallel workers at runtime
От | Dilip Kumar |
---|---|
Тема | Re: [HACKERS] Increasing parallel workers at runtime |
Дата | |
Msg-id | CAFiTN-sSMWx0fKLLJkhJaKJ0Gp1YLkf1P+nbUWKQAfZ9gverMg@mail.gmail.com обсуждение исходный текст |
Ответ на | [HACKERS] Increasing parallel workers at runtime (Haribabu Kommi <kommi.haribabu@gmail.com>) |
Список | pgsql-hackers |
On Mon, May 15, 2017 at 7:36 PM, Haribabu Kommi <kommi.haribabu@gmail.com> wrote: > > The wait of the workers to send tuples is may be > because of less number of workers. So increasing > the parallel workers may improve the performance. Yes, for the cases where a significant amount of work is still pending, but it might hurt the performance where the work is about to complete but not yet completed. @@ -346,6 +346,38 @@ gather_readnext(GatherState *gatherstate) if (nvisited >= gatherstate->nreaders) { /* + * As we are going to wait for the workers to send tuples, this may be + * possible because of not sufficient workers that are planned? + * Does the gather have all the required parallel workers? If not try to get + * some more workers (only when all the previously allocated workers are still + * doing the job) before we wait, this will further increase the performance + * of the query as planned. + */ You might want to do similar changes for gather_merge_readnext. -- Regards, Dilip Kumar EnterpriseDB: http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: