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:29:50 |
Message-ID: | 5C85F24E.4050404@lab.ntt.co.jp |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
(2019/03/11 14:14), Tom Lane wrote:
> Etsuro Fujita<fujita(dot)etsuro(at)lab(dot)ntt(dot)co(dot)jp> writes:
>> (2019/03/11 13:06), Tom Lane wrote:
>>> 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.
>
> Seems to me it's the other way around: the final target would include
> all functions invoked in the grouping target plus maybe some more.
> So a non-parallel-safe grouping target implies a non-parallel-safe
> final target, but not vice versa.
I mean the final *scan/join* target, not the final target.
Best regards,
Etsuro Fujita
From | Date | Subject | |
---|---|---|---|
Next Message | Masahiko Sawada | 2019-03-11 06:23:53 | Re: A separate table level option to control compression |
Previous Message | Tom Lane | 2019-03-11 05:14:21 | Re: Oddity with parallel safety test for scan/join target in grouping_planner |