Horton

Re: Query running for very long time (server hanged) with parallel append

Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp>

View thread View on postgr.es
From: Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp>
To: robertmhaas@gmail.com
Cc: amitdkhan.pg@gmail.com, thomas.munro@enterprisedb.com, rajkumar.raghuwanshi@enterprisedb.com, pgsql-hackers@postgresql.org
Date: 2018-02-07T02:00:49Z
Lists: 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

Commits

  1. Fix possible infinite loop with Parallel Append.