On Wed, Nov 29, 2017 at 2:04 PM, Amit Kapila <amit.kapil...@gmail.com> wrote: > On Tue, Nov 28, 2017 at 9:42 PM, Robert Haas <robertmh...@gmail.com> wrote: >> On Tue, Nov 28, 2017 at 2:23 AM, Amit Kapila <amit.kapil...@gmail.com> wrote: >>> That is wrong and I think you have hit a bug. It should be 2974 * 5 = >>> 14870 as you have seen in other cases. The problem is that during >>> rescan, we generally reinitialize the required state, but we forgot to >>> reinitialize the instrumentation related memory which is used in the >>> accumulation of stats, so changing that would fix some part of this >>> problem which is that at Parallel node, you won't see wrong values. >>> However, we also need to ensure that the per-worker details also get >>> accumulated across rescans. Attached patch should fix the problem you >>> are seeing. I think this needs some more analysis and testing to see >>> if everything works in the desired way. >>> >>> Is it possible for you to test the attached patch and see if you are >>> still seeing any unexpected values? >> >> FWIW, this looks sensible to me. Not sure if there's any good way to >> write a regression test for it. >> > > I think so, but not 100% sure. I will give it a try and report back. >
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. -- With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com
fix_accum_instr_parallel_workers_v2.patch
Description: Binary data
