Re: auto_explain vs. parallel query
От | Tomas Vondra |
---|---|
Тема | Re: auto_explain vs. parallel query |
Дата | |
Msg-id | 9e9647b0-7526-0e9f-3aca-fa058f29c64d@2ndquadrant.com обсуждение исходный текст |
Ответ на | Re: auto_explain vs. parallel query (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: auto_explain vs. parallel query
|
Список | pgsql-hackers |
On 11/01/2016 08:32 PM, Robert Haas wrote: > On Tue, Nov 1, 2016 at 10:58 AM, Tomas Vondra > <tomas.vondra@2ndquadrant.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
В списке pgsql-hackers по дате отправления: