Re: [HACKERS] Increasing parallel workers at runtime - Mailing list pgsql-hackers

From Robert Haas
Subject Re: [HACKERS] Increasing parallel workers at runtime
Date
Msg-id CA+TgmoZ2By5hF5jX+4F_i4KShoz_u+SoSV9WM9V_X4+N=mxZHQ@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] Increasing parallel workers at runtime  (Haribabu Kommi <kommi.haribabu@gmail.com>)
List pgsql-hackers
On Tue, May 16, 2017 at 8:15 PM, Haribabu Kommi
<kommi.haribabu@gmail.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



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: [HACKERS] UPDATE of partition key
Next
From: Rushabh Lathia
Date:
Subject: Re: [HACKERS] UPDATE of partition key