From: Tom Lane <tgl@sss.pgh.pa.us>
To: Etsuro Fujita <fujita.etsuro@lab.ntt.co.jp>
cc: Robert Haas <robertmhaas@gmail.com>,
        Pg Hackers <pgsql-hackers@postgresql.org>
Subject: Re: Oddity with parallel safety test for scan/join target in
 grouping_planner
In-reply-to: <5C85DC65.2050409@lab.ntt.co.jp>
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>
Comments: In-reply-to Etsuro Fujita <fujita.etsuro@lab.ntt.co.jp>
	message dated "Mon, 11 Mar 2019 12:56:21 +0900"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <32400.1552277190.1@sss.pgh.pa.us>
Date: Mon, 11 Mar 2019 00:06:30 -0400
Message-ID: <32401.1552277190@sss.pgh.pa.us>
Precedence: bulk

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.  If the wrong answer can only be wrong
in the safe direction, it's not very clear why.

			regards, tom lane