On Fri, Jul 1, 2016 at 10:52 AM, Tom Lane wrote:
> Robert Haas writes:
>> On Thu, Jun 30, 2016 at 5:54 PM, Tom Lane wrote:
>>> And the point of that is what, exactly? If the only change is that
>>> "some restrictions get enforced", I am not clear on why we need such
>>> a test mode in cases whe
On Fri, Jul 1, 2016 at 11:09 AM, Tom Lane wrote:
> Robert Haas writes:
>> On Thu, Jun 30, 2016 at 5:54 PM, Tom Lane wrote:
>>> Don't have time to re-read this right now, but maybe tomorrow or
>>> Saturday.
>
>> OK, thanks.
>
> There's still the extra-word problem here:
>
> +* If the inpu
Robert Haas writes:
> On Thu, Jun 30, 2016 at 5:54 PM, Tom Lane wrote:
>> Don't have time to re-read this right now, but maybe tomorrow or
>> Saturday.
> OK, thanks.
There's still the extra-word problem here:
+* If the input rel is marked consider_parallel and there's nothing
+
Robert Haas writes:
> On Thu, Jun 30, 2016 at 5:54 PM, Tom Lane wrote:
>> And the point of that is what, exactly? If the only change is that
>> "some restrictions get enforced", I am not clear on why we need such
>> a test mode in cases where the planner is afraid to put a top Gather on
>> the p
On Thu, Jun 30, 2016 at 5:54 PM, Tom Lane wrote:
>> That's pretty much right, but there are two conceptually separate
>> things. The first is whether or not we actually attempt to spawn
>> workers, and the second is whether or not we enter parallel mode.
>> Entering parallel mode enables various
On Thu, Jun 30, 2016 at 1:13 PM, Tom Lane wrote:
> BTW, I just had another thought about reducing the cost of
> has_parallel_hazard checks, to wit: you already made one pass over the
> entire query to verify that there's no PARALLEL UNSAFE functions anywhere.
> If that pass were to also track whet
Robert Haas writes:
> On Thu, Jun 30, 2016 at 12:04 PM, Tom Lane wrote:
>> * It seems like the initialization of root->parallelModeNeeded is still
>> overcomplicated and/or underexplained.
> That's pretty much right, but there are two conceptually separate
> things. The first is whether or not
On Thu, Jun 30, 2016 at 12:04 PM, Tom Lane wrote:
> Robert Haas writes:
>> Here is a new patch addressing (I hope) the above comments and a few
>> other things.
>
> Some more comments:
>
> * It seems like the initialization of root->parallelModeNeeded is still
> overcomplicated and/or underexplai
BTW, I just had another thought about reducing the cost of
has_parallel_hazard checks, to wit: you already made one pass over the
entire query to verify that there's no PARALLEL UNSAFE functions anywhere.
If that pass were to also track whether there are any PARALLEL RESTRICTED
functions anywhere,
Robert Haas writes:
> Here is a new patch addressing (I hope) the above comments and a few
> other things.
Some more comments:
* It seems like the initialization of root->parallelModeNeeded is still
overcomplicated and/or underexplained. Why do you not merely set it false
to start with, and all
On Mon, Jun 27, 2016 at 4:49 PM, Tom Lane wrote:
> A few specific comments:
>
> * Can't we remove wholePlanParallelSafe altogether, in favor of just
> examining best_path->parallel_safe in standard_planner?
>
> * In grouping_planner, I'm not exactly convinced that
> final_rel->consider_parallel ca
On Wed, Jun 29, 2016 at 1:26 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Mon, Jun 27, 2016 at 6:04 PM, Tom Lane wrote:
>>> Huh? The final tlist would go with the final_rel, ISTM, not the scan
>>> relation. Maybe we have some rejiggering to do to make that true, though.
>
>> Mumble. You're
Robert Haas writes:
> On Mon, Jun 27, 2016 at 6:04 PM, Tom Lane wrote:
>> Huh? The final tlist would go with the final_rel, ISTM, not the scan
>> relation. Maybe we have some rejiggering to do to make that true, though.
> Mumble. You're right that there are two rels involved, but I think
> I'
On Mon, Jun 27, 2016 at 6:04 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Mon, Jun 27, 2016 at 5:28 PM, Tom Lane wrote:
>>> Seems to me that it should generally be the case that consider_parallel
>>> would already be clear on the parent rel if the tlist isn't parallel safe,
>>> and if it isn'
Robert Haas writes:
> On Mon, Jun 27, 2016 at 5:28 PM, Tom Lane wrote:
>> Seems to me that it should generally be the case that consider_parallel
>> would already be clear on the parent rel if the tlist isn't parallel safe,
>> and if it isn't we probably have a bug elsewhere. If it makes you fee
On Mon, Jun 27, 2016 at 5:28 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Mon, Jun 27, 2016 at 4:49 PM, Tom Lane wrote:
>>> * Not following what you did to apply_projection_to_path, and the comment
>>> therein isn't helping.
>
>> Gee, I wonder why not? :-)
>
>> The basic problem here is that
Robert Haas writes:
> On Mon, Jun 27, 2016 at 4:49 PM, Tom Lane wrote:
>> * Not following what you did to apply_projection_to_path, and the comment
>> therein isn't helping.
> Gee, I wonder why not? :-)
> The basic problem here is that applying a projection to a path can
> render a formerly pa
On Mon, Jun 27, 2016 at 4:49 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Mon, Jun 27, 2016 at 3:35 PM, Tom Lane wrote:
>>> Oh, I thought you were still actively working on it. What patch do
>>> you want me to review?
>
>> I'm looking for an opinion on the WIP patch attached to:
>> https://w
Robert Haas writes:
> On Mon, Jun 27, 2016 at 3:35 PM, Tom Lane wrote:
>> Oh, I thought you were still actively working on it. What patch do
>> you want me to review?
> I'm looking for an opinion on the WIP patch attached to:
> https://www.postgresql.org/message-id/ca+tgmozwjb9eaibj-meeaq913wkk
On Mon, Jun 27, 2016 at 3:35 PM, Tom Lane wrote:
> Robert Haas writes:
>> I'm not sure how to proceed here. I have asked Tom several times to
>> look at the WIP patch and offer comments, but he so far has not done
>> so.
>
> Oh, I thought you were still actively working on it. What patch do
> y
Robert Haas writes:
> I'm not sure how to proceed here. I have asked Tom several times to
> look at the WIP patch and offer comments, but he so far has not done
> so.
Oh, I thought you were still actively working on it. What patch do
you want me to review?
regards, tom
On Sun, Jun 26, 2016 at 10:42 PM, Noah Misch wrote:
> On Mon, Jun 13, 2016 at 05:27:13PM -0400, Robert Haas wrote:
>> One problem that I've realized that is related to this is that the way
>> that the consider_parallel flag is being set for upper rels is almost
>> totally bogus, which I believe ac
22 matches
Mail list logo
