On Fri, Sep 18, 2015 at 5:24 AM, Kouhei Kaigai wrote:
>> On Thu, Sep 17, 2015 at 9:01 PM, Kouhei Kaigai wrote:
>> > I entirely agree with the idea of plan-node identifier, however,
>> > uncertain whether the node-id shall represent physical location on
>> > the dynamic shared memory segment, beca
> On Thu, Sep 17, 2015 at 9:01 PM, Kouhei Kaigai wrote:
> > I entirely agree with the idea of plan-node identifier, however,
> > uncertain whether the node-id shall represent physical location on
> > the dynamic shared memory segment, because
> > (1) Relatively smaller number of node type needs sh
On Thu, Sep 17, 2015 at 9:01 PM, Kouhei Kaigai wrote:
> I entirely agree with the idea of plan-node identifier, however,
> uncertain whether the node-id shall represent physical location on
> the dynamic shared memory segment, because
> (1) Relatively smaller number of node type needs shared state
> One of the problems which the remaining parallel query patches need to
> solve is to correlate Plan or PlanState nodes across multiple
> backends. This need arises in a couple of cases. First, if a group
> of workers are all executing the same plan nodes, and es_instrument !=
> 0, then we'll ac
On Thu, Sep 17, 2015 at 5:19 PM, Simon Riggs wrote:
> Passing array offsets sounds brittle to me.
How would this case be any different from other places in the planner
where we already do exactly that? For example, RTIs.
> It would screw up any attempts to post-process the plans. Later enhancem
On Thu, Sep 17, 2015 at 4:22 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Thu, Sep 17, 2015 at 2:23 PM, Tom Lane wrote:
>>> I can't imagine I'd be doing anything that would break the simple case
>>> of "give every node a distinct ID". If you are building in weird
>>> assumptions about traver
On 17 September 2015 at 13:14, Robert Haas wrote:
> My main concern with this design is how future-proof it is.
>
Passing array offsets sounds brittle to me.
It would screw up any attempts to post-process the plans. Later
enhancements seem certain to break that scheme.
It also assumes that al
Robert Haas writes:
> On Thu, Sep 17, 2015 at 2:23 PM, Tom Lane wrote:
>> I can't imagine I'd be doing anything that would break the simple case
>> of "give every node a distinct ID". If you are building in weird
>> assumptions about traversal order, that might indeed be a problem.
> Good to kn
Thanks much for the quick reply.
On Thu, Sep 17, 2015 at 2:23 PM, Tom Lane wrote:
>> It would be nice if we could assign the integer IDs with no gaps, and
>> with the IDs of a node's children immediately following that of their
>> parent.
>
> I do not think this should be a goal, either explicitl
Robert Haas writes:
> To meet these needs, what I propose to do is have
> set_plan_references() assign an integer ID to every plan node that is
> unique across the entire plan tree.
OK.
> It would be nice if we could assign the integer IDs with no gaps, and
> with the IDs of a node's children im
Hi,
One of the problems which the remaining parallel query patches need to
solve is to correlate Plan or PlanState nodes across multiple
backends. This need arises in a couple of cases. First, if a group
of workers are all executing the same plan nodes, and es_instrument !=
0, then we'll accumul
11 matches
Mail list logo
