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 |
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 |