Re: [HACKERS] Increasing parallel workers at runtime

Поиск
Список
Период
Сортировка
От Haribabu Kommi
Тема Re: [HACKERS] Increasing parallel workers at runtime
Дата
Msg-id CAJrrPGd-99xurp+X_u9APrNAcS1QfQUyWWgYs1oj8dHYAvyemQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [HACKERS] Increasing parallel workers at runtime  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: [HACKERS] Increasing parallel workers at runtime  (Amit Kapila <amit.kapila16@gmail.com>)
Re: [HACKERS] Increasing parallel workers at runtime  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers


On Wed, May 17, 2017 at 2:35 AM, Robert Haas <robertmhaas@gmail.com> wrote:
On Tue, May 16, 2017 at 8:18 AM, Haribabu Kommi
<kommi.haribabu@gmail.com> wrote:
> In the current state of the patch, the main backend tries to start the
> extra workers only when there is no tuples that are available from the
> available workers. I feel that the invocation for more workers doesn't
> do for every tuple.

Well, the point is, the frequency with which the leader will try to
acquire more workers is going to be highly variable with your patch,
and might sometimes be extremely frequent.  It depends on the timing
of the workers and of the leader, and I don't think that's something
we want to depend on here.

Ok.
 
> Another background process logic can produce a fair distribution of
> workers to the parallel queries. In this case also, the backend should
> advertise only when the allotted workers are not enough, this is because
> there may be a case where the planned workers may be 5, but because
> of other part of the query, the main backend is feed by the tuples just by
> 2 workers, then there is no need to provide extra workers.

That's true, but I think taking it into account might be difficult.

> The another background process approach of wait interval to reassign
> more workers after an interval period doesn't work for the queries that
> are getting finished before the configured time of the wait. May be we
> can ignore those scenarios?

I think we can ignore that.  We can still help a lot of cases, and
queries with very short run times obviously aren't being seriously
hurt by the lack of full parallelism.

Ok. In this approach, we need to share some of the gatherstate structure
members in the shared memory to access by the other background process
or some better logic to update these details whenever a new worker gets
allotted.

I will give a try and see how easy to implement the same.

Regards,
Hari Babu
Fujitsu Australia

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Michael Paquier
Дата:
Сообщение: Re: [HACKERS] synchronous_commit option is not visible after pressing TAB
Следующее
От: Amit Langote
Дата:
Сообщение: Re: [HACKERS] NOT NULL constraints on range partition key columns