On Mon, Dec 4, 2017 at 11:17 PM, Robert Haas <robertmh...@gmail.com> wrote: > On Sat, Dec 2, 2017 at 8:04 AM, Amit Kapila <amit.kapil...@gmail.com> wrote: >> Attached patch contains regression test as well. Note that I have >> carefully disabled all variable stats by using (analyze, timing off, >> summary off, costs off) and then selected parallel sequential scan on >> the right of join so that we have nloops and rows as variable stats >> and those should remain constant. > > The regression test contains a whitespace error about which git diff > --check complains. >
oops, a silly mistake from my side. > Also, looking at this again, shouldn't the reinitialization of the > instrumentation arrays happen in ExecParallelReinitialize rather than > ExecParallelFinish, so that we don't spend time doing it unless the > Gather is actually re-executed? > Yeah, that sounds better, so modified the patch accordingly. 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. -- With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com
fix_accum_instr_parallel_workers_v3.patch
Description: Binary data
