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