Re: Oddity with parallel safety test for scan/join target in grouping_planner
От | Tom Lane |
---|---|
Тема | Re: Oddity with parallel safety test for scan/join target in grouping_planner |
Дата | |
Msg-id | 1962.1552281261@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Oddity with parallel safety test for scan/join target in grouping_planner (Etsuro Fujita <fujita.etsuro@lab.ntt.co.jp>) |
Ответы |
Re: Oddity with parallel safety test for scan/join target in grouping_planner
|
Список | pgsql-hackers |
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. Possibly the summary had it backwards and the actual code bug is inferring things in the safe direction, but I'm too tired to double check that right now ... regards, tom lane
В списке pgsql-hackers по дате отправления: