Re: explain analyze output with parallel workers - question aboutmeaning of information for explain.depesz.com
От | Robert Haas |
---|---|
Тема | Re: explain analyze output with parallel workers - question aboutmeaning of information for explain.depesz.com |
Дата | |
Msg-id | CA+Tgmob0DqZJnwP_28TCqGHNNKAB_2cTNDp=2bUbkTBFeMSwDA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: explain analyze output with parallel workers - question aboutmeaning of information for explain.depesz.com (Amit Kapila <amit.kapila16@gmail.com>) |
Ответы |
Re: explain analyze output with parallel workers - question aboutmeaning of information for explain.depesz.com
|
Список | pgsql-hackers |
On Tue, Nov 28, 2017 at 2:23 AM, Amit Kapila <amit.kapila16@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. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: