Re: Increasing parallel workers at runtime

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Haribabu Kommi <kommi(dot)haribabu(at)gmail(dot)com>
Cc: "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Increasing parallel workers at runtime
Date: 2017-05-17 11:52:48
Message-ID: CA+TgmoZ2By5hF5jX+4F_i4KShoz_u+SoSV9WM9V_X4+N=mxZHQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, May 16, 2017 at 8:15 PM, Haribabu Kommi
<kommi(dot)haribabu(at)gmail(dot)com> wrote:
> 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.

What I'm imagining is a shared memory array with up to, say, 32 slots
(or, say, max_worker_processes slots). Each slot stores the PID of
the leader, the number of workers expected, and the number of workers
actually obtained. The leader tries to claim a slot for its details
(just giving up if there are none available) and clears the slot again
at the end of the query (if it got one, and even in case of error).
The whole array is protected by a new LWLock.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Rushabh Lathia 2017-05-17 11:59:08 Re: UPDATE of partition key
Previous Message Robert Haas 2017-05-17 11:47:51 Re: UPDATE of partition key