Message-ID: <5C85ED63.8000805@lab.ntt.co.jp>
Date: Mon, 11 Mar 2019 14:08:51 +0900
From: Etsuro Fujita <fujita.etsuro@lab.ntt.co.jp>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
 rv:11.0) Gecko/20120327 Thunderbird/11.0.1
MIME-Version: 1.0
Subject: Re: Oddity with parallel safety test for scan/join target in
 grouping_planner
References: <5C75303E.8020303@lab.ntt.co.jp>
 <CA+TgmobmV=Zw2OEJKUorJe=e+_fCzsvYErR6tXxTjCzK45x9RQ@mail.gmail.com>
 <5C7908B9.5070407@lab.ntt.co.jp> <24818.1552077419@sss.pgh.pa.us>
 <5C85DC65.2050409@lab.ntt.co.jp> <32401.1552277190@sss.pgh.pa.us>
In-Reply-To: <32401.1552277190@sss.pgh.pa.us>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Robert Haas <robertmhaas@gmail.com>,
        Pg Hackers <pgsql-hackers@postgresql.org>
Precedence: bulk

(2019/03/11 13:06), Tom Lane wrote:
> Etsuro Fujita<fujita.etsuro@lab.ntt.co.jp>  writes:
>>>> The parallel safety of the final scan/join target is determined from the
>>>> grouping target, not that target, which [ is wrong ]
>
>> This would only affect plan quality a little bit, so I don't think we
>> need a regression test for this, either, but the fix might destabilize
>> existing plan choices, so we should apply it to HEAD only?
>
> Is that the only possible outcome?  Per Robert's summary quoted above,
> it seems like it might be possible for the code to decide that the final
> scan/join target to be parallel safe when it is not, leading to outright
> wrong answers or query failures.

Maybe I'm missing something, but I think that if the final scan/join 
target is not parallel-safe, then the grouping target would not be 
parallel-safe either, by the construction of the two targets, so I don't 
think that we have such a correctness issue.

Best regards,
Etsuro Fujita