Re: Oddity with parallel safety test for scan/join target in grouping_planner
От | Etsuro Fujita |
---|---|
Тема | Re: Oddity with parallel safety test for scan/join target in grouping_planner |
Дата | |
Msg-id | 5C85F24E.4050404@lab.ntt.co.jp обсуждение исходный текст |
Ответ на | Re: Oddity with parallel safety test for scan/join target in grouping_planner (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Oddity with parallel safety test for scan/join target in grouping_planner
|
Список | pgsql-hackers |
(2019/03/11 14:14), Tom Lane wrote: > Etsuro Fujita<fujita.etsuro@lab.ntt.co.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
В списке pgsql-hackers по дате отправления: