Re: Query running for very long time (server hanged) with parallelappend
От | Kyotaro HORIGUCHI |
---|---|
Тема | Re: Query running for very long time (server hanged) with parallelappend |
Дата | |
Msg-id | 20180207.110049.256524990.horiguchi.kyotaro@lab.ntt.co.jp обсуждение исходный текст |
Ответ на | Re: Query running for very long time (server hanged) with parallel append (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: Query running for very long time (server hanged) with parallel append
|
Список | pgsql-hackers |
At Tue, 6 Feb 2018 13:50:28 -0500, Robert Haas <robertmhaas@gmail.com> wrote in <CA+TgmoYqdC+9U8mLYkUgM=CaBt6Pzz4R_YNboqDbW-LvUaHO+g@mail.gmail.com> > On Tue, Feb 6, 2018 at 11:32 AM, Amit Khandekar <amitdkhan.pg@gmail.com> wrote: > > Yeah, I think it looks equally good that way, and like you said, the > > current code does it that way. So in the attached patch, I have > > swapped the two conditions. > > I prefer to avoid introducing 2 new variables and instead just prevent > the looping directly in the case where we started with a non-partial > plan. > > See attached. Does this look OK? Ah, we can bail out when starting from the first partial plan. It's a bit uneasy that pa_next_plan can be -1 but it looks perfect to me. regards, -- Kyotaro Horiguchi NTT Open Source Software Center
В списке pgsql-hackers по дате отправления: