Re: explain analyze output with parallel workers - question aboutmeaning of information for explain.depesz.com

On Tue, Dec 5, 2017 at 8:49 PM, Thomas Munro
<thomas.munro@enterprisedb.com> wrote:
> On Tue, Dec 5, 2017 at 6:39 PM, Amit Kapila <amit.kapila16@gmail.com> wrote:
>> I have one another observation in the somewhat related area.  From the
>> code, it looks like we might have some problem with displaying sort
>> info for workers for rescans.  I think the problem with the sortinfo
>> is that it initializes shared info with local memory in
>> ExecSortRetrieveInstrumentation after which it won't be able to access
>> the values in shared memory changed by workers in rescans.  We might
>> be able to fix it by having some local_info same as sahred_info in
>> sort node.  But the main problem is how do we accumulate stats for
>> workers across rescans.  The type of sort method can change across
>> rescans.  We might be able to accumulate the size of Memory though,
>> but not sure if that is right.  I think though this appears to be
>> somewhat related to the problem being discussed in this thread, it can
>> be dealt separately if we want to fix it.
>
> Yeah, that's broken.  ExecSortRetrieveInstrumentation() is run for
> each loop, and after the first loop we've lost track of the pointer
> into shared memory because we replaced it with palloc'd copy.  We
> could do what you said, or we could reinstate the pointer into the DSM
> in ExecSortReInitializeDSM() by looking it up in the TOC.

Or would it be an option to change the time
ExecXXXRetrieveInstrumentation() is called so it is run only once?

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