| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Etsuro Fujita <fujita(dot)etsuro(at)lab(dot)ntt(dot)co(dot)jp> |
| 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 04:06:30 |
| Message-ID: | 32401.1552277190@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | Postg토토 커뮤니티SQL |
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. If the wrong answer can only be wrong
in the safe direction, it's not very clear why.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Justin Pryzby | 2019-03-11 04:22:44 | Re: Should we add GUCs to allow partition pruning to be disabled? |
| Previous Message | Amit Langote | 2019-03-11 04:06:08 | Re: Should we add GUCs to allow partition pruning to be disabled? |