On Tue, Dec 5, 2017 at 8:49 PM, Thomas Munro <thomas.mu...@enterprisedb.com> wrote: > On Tue, Dec 5, 2017 at 6:39 PM, Amit Kapila <amit.kapil...@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