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 по дате отправления:

Предыдущее
От: Peter Geoghegan
Дата:
Сообщение: Re: PostgreSQL crashes with SIGSEGV
Следующее
От: Masahiko Sawada
Дата:
Сообщение: Re: Failed to request an autovacuum work-item in silence