From: | Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: auto_explain vs. parallel query |
Date: | 2016-11-02 16:49:16 |
Message-ID: | 9e9647b0-7526-0e9f-3aca-fa058f29c64d@2ndquadrant.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 11/01/2016 08:32 PM, Robert Haas wrote:
> On Tue, Nov 1, 2016 at 10:58 AM, Tomas Vondra
> <tomas(dot)vondra(at)2ndquadrant(dot)com> wrote:
>> Damn! You're right of course. Who'd guess I need more coffee this early?
>>
>> Attached is a fix replacing the flag with an array of flags, indexed by
>> ParallelMasterBackendId. Hopefully that makes it work with multiple
>> concurrent parallel queries ... still, I'm not sure this is the right
>> solution.
>
> I feel like it isn't. I feel like this ought to go in the DSM for
> that parallel query, not the main shared memory segment, but I'm not
> sure how to accomplish that offhand. Also, if we do solve it this
> way, surely we don't need the locking. The flag's only set before any
> workers have started and never changes thereafter.
>
I'm not sure what you mean by "DSM for that parallel query" - I thought
the segments are created for Gather nodes, no? Or is there a DSM for the
whole query that we could use?
Another thing is that maybe we don't really want to give extensions
access to any of those segments - my impression was those segments are
considered internal (is there RequestAddinShmemSpace for them?). And
hacking something just for auto_explain seems a big ugly.
regards
--
Tomas Vondra http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Amit Kapila | 2016-11-02 16:52:45 | Re: Speed up Clog Access by increasing CLOG buffers |
Previous Message | Jesper Pedersen | 2016-11-02 16:43:42 | Re: pageinspect: Hash index support |