(2019/03/11 23:46), Tom Lane wrote:
So this is
just a plan-quality problem not a wrong-answer problem.
However, I'd still argue for back-patching into v11, on the grounds
that this is a regression from v10. The example you just gave does
produce the desired plan in v10, and I think it's more li
Etsuro Fujita writes:
> (2019/03/11 14:14), Tom Lane wrote:
>> 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
(2019/03/11 14:14), Tom Lane wrote:
Etsuro Fujita 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, lea
Etsuro Fujita 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 ans
(2019/03/11 13:06), Tom Lane wrote:
Etsuro Fujita 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, eithe
Etsuro Fujita 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 destabi
(2019/03/09 5:36), Tom Lane wrote:
Etsuro Fujita writes:
(2019/02/28 0:52), Robert Haas wrote:
On Tue, Feb 26, 2019 at 7:26 AM Etsuro Fujita
wrote:
The parallel safety of the final scan/join target is determined from the
grouping target, not that target, which [ is wrong ]
Your patch lo
Etsuro Fujita writes:
> (2019/02/28 0:52), Robert Haas wrote:
>> On Tue, Feb 26, 2019 at 7:26 AM Etsuro Fujita
>> wrote:
>>> The parallel safety of the final scan/join target is determined from the
>>> grouping target, not that target, which [ is wrong ]
>> Your patch looks right to me.
> I th
(2019/02/28 0:52), Robert Haas wrote:
On Tue, Feb 26, 2019 at 7:26 AM Etsuro Fujita
wrote:
The parallel safety of the final scan/join target is determined from the
grouping target, not that target, which [ is wrong ]
Your patch looks right to me.
I think it would be better for you to take
On Tue, Feb 26, 2019 at 7:26 AM Etsuro Fujita
wrote:
> The parallel safety of the final scan/join target is determined from the
> grouping target, not that target, which [ is wrong ]
OOPS. That's pretty embarrassing.
Your patch looks right to me. I will now go look for a bag to put over my hea
(2019/02/26 21:25), Etsuro Fujita wrote:
> While working on [1], I noticed $Subject, that is:
>
> /*
> * If we have grouping or aggregation to do, the topmost scan/join
> * plan node must emit what the grouping step wants; otherwise, it
> * should emit groupi
11 matches
Mail list logo
