Re: Creating a DSA area to provide work space for parallel execution

From: Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com>
To: Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Creating a DSA area to provide work space for parallel execution
Date: 2016-11-23 12:12:41
Message-ID: CAEepm=1-okw2y95=vxpkJEkLWEJwfM+BEG7m9hgtZkM802aVZg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Oct 5, 2016 at 10:32 AM, Thomas Munro
<thomas(dot)munro(at)enterprisedb(dot)com> wrote:
> One obvious problem is that this patch results in at least *two* DSM
> segments being created for every parallel query execution: the main
> segment used for parallel execution, and then the initial segment
> managed by the DSA area. One thought is that DSA areas are the more
> general mechanism, so perhaps we should figure out how to store
> contents of the existing segment in it. The TOC interface would need
> a few tweaks to be able to live in memory allocated with dsa_allocate,
> and they we'd need to share that address with other backends so that
> they could find it (cf the current approach of finding the TOC at the
> start of the segment). I haven't prototyped that yet. That'd involve
> changing the wording "InitializeDSM" that appears in various places
> including the FDW API, which has been putting me off...

... or we could allow DSA areas to be constructed inside existing
shmem, as in the attached patch which requires dsa_create_in_place,
from the patch at
https://www.postgresql.org/message-id/CAEepm%3D0-pbokaQdCXhtYn%3Dw64MmdJz4hYW7qcSU235ar276x7w%40mail.gmail.com
.

--
Thomas Munro
http://www.enterprisedb.com

Attachment Content-Type Size
dsa-area-for-executor-v2.patch application/octet-stream 5.4 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Daniel Verite 2016-11-23 12:17:31 Re: Improvements in psql hooks for variables
Previous Message Thomas Munro 2016-11-23 12:07:39 Re: Dynamic shared memory areas