| From: | Etsuro Fujita <fujita(dot)etsuro(at)lab(dot)ntt(dot)co(dot)jp> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Oddity with parallel safety test for scan/join target in grouping_planner |
| Date: | 2019-03-11 05:08:51 |
| Message-ID: | 5C85ED63.8000805@lab.ntt.co.jp |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
(2019/03/11 13:06), Tom Lane wrote:
> Etsuro Fujita<fujita(dot)etsuro(at)lab(dot)ntt(dot)co(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | amul sul | 2019-03-11 05:09:46 | Re: [HACKERS] advanced partition matching algorithm for partition-wise join |
| Previous Message | Michael Paquier | 2019-03-11 04:53:23 | Re: Offline enabling/disabling of data checksums |