Robert Haas <robertmh...@gmail.com> 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 immediately following that of their
> parent.
I do not think this should be a goal, either explicitly or implicitly.
For one thing, it will be very much in the eye of individual beholders
which nodes are children-that-should-be-consecutive. What about
initplans, subplans, grandchild nodes? Different use cases could easily
have different opinions about what to do with those.
> The advantage of this is that if you want to have a data
> structure for every node in the tree passed to some worker - like a
> struct Instrumentation in dynamic shared memory - you can just create
> an array and index it by (node ID) - (node ID of uppermost child
> passed to worker), and every slot will be in use, so no memory is
> wasted and no lookup table is needed.
I think you could just waste the memory, or more likely you could cope
with one level of indirection so that you only waste a pointer per
node (ie, array of pointers indexed by node ID, only fill the ones that
are relevant).
> My main concern with this design is how future-proof it is. I know
> Tom is working on ripping the planner apart and putting it back
> together again to allow the upper levels of the planner to use paths,
> and the discussion of the SS_finalize_plan() changes made some
> reference to possibly wanting to mess with set_plan_references().
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.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
