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

From: Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp>
To: robertmhaas(at)gmail(dot)com
Cc: amitdkhan(dot)pg(at)gmail(dot)com, thomas(dot)munro(at)enterprisedb(dot)com, rajkumar(dot)raghuwanshi(at)enterprisedb(dot)com, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Query running for very long time (server hanged) with parallel append
Date: 2018-02-07 02:00:49
Message-ID: 20180207.110049.256524990.horiguchi.kyotaro@lab.ntt.co.jp
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

At Tue, 6 Feb 2018 13:50:28 -0500, Robert Haas <robertmhaas(at)gmail(dot)com> wrote in <CA+TgmoYqdC+9U8mLYkUgM=CaBt6Pzz4R_YNboqDbW-LvUaHO+g(at)mail(dot)gmail(dot)com>
> On Tue, Feb 6, 2018 at 11:32 AM, Amit Khandekar <amitdkhan(dot)pg(at)gmail(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Masahiko Sawada 2018-02-07 02:20:08 Re: Failed to request an autovacuum work-item in silence
Previous Message Peter Geoghegan 2018-02-07 01:56:25 Re: PostgreSQL crashes with SIGSEGV