I've been taking a look at how to stop the planner from scribbling on its input. This is my first modification of any significance to the planner, so don't hesitate to tell me what I've gotten wrong :)

I think the planner makes two kinds of modifications to the input Query: (a) rewriting of the Query to improve planning (b) as a convenient place to store planner working state. Some examples of the former include transforming IN clauses to joins, transforming simple FROM-clause subselects into joins, preprocessing expressions, and so forth. Examples of the latter are mostly the "internal to planner" fields denoted in the Query struct definition.

(b) should be pretty easy to solve; we can create a per-Query PlanState struct that contains this information, as well as holding a pointer to the Query (and perhaps the in-construct Plan tree).

I'm still trying to figure out how to handle (a). Perhaps we can create an additional plan node that always sits at the top of the plan tree. This would hold derivations of data from the input Query. A lot of the code that implements (a) is actually already applicative in nature, but any code that modifies a Query destructively would need to be changed. In other words, rather than

    query->jointree = pull_up_subqueries(parse, query->jointree);

We'd have:

    top_plan_node->jointree = pull_up_subqueries(plan_state,
                                                 query->jointree);

(Possibly passing PlanState rather than `parse', which is a Query, if needed. The example is also somewhat simplified.)

BTW, I wonder whether it would be possible to move some preprocessing from the early stages of the planner to a "preprocessing" phase that would run after the rewriter but before the planner proper. The preprocessor would maintain the essential properties of the input Query, but it wouldn't need to be re-run when the query is replanned due to a modification to a dependent database object. For example, the decision about whether to pull-up a subquery could be done once and not redone in subsequent invocations of the planner on the same Query. On the other hand, I'm not sure how much preprocessing could be rearranged like this, and since replanning ought to be relatively rare, I'm not sure it's worth spending a whole lot of time trying to optimize it...

Comments welcome.

-Neil


---------------------------(end of broadcast)--------------------------- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])

Reply via email to