From: Tom Lane <tgl@sss.pgh.pa.us>
To: Etsuro Fujita <fujita.etsuro@lab.ntt.co.jp>
Cc: Robert Haas <robertmhaas@gmail.com>
Cc: Pg Hackers <pgsql-hackers@postgresql.org>
Subject: Re: Oddity with parallel safety test for scan/join target in grouping_planner
Date: Mon, 11 Mar 2019 00:06:30 -0400
Message-ID: <32401.1552277190@sss.pgh.pa.us> (raw)
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>
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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: tgl@sss.pgh.pa.us, fujita.etsuro@lab.ntt.co.jp, robertmhaas@gmail.com
Subject: Re: Oddity with parallel safety test for scan/join target in grouping_planner
In-Reply-To: <32401.1552277190@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox