Neil Conway <[EMAIL PROTECTED]> writes:
> 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.
I don't believe there is any very significant amount of planner work
that is completely independent of any external database object. For
that matter, even the rewriter needs to be rerun when any views or
defaults change in the query. And for that matter, even the parse
analysis phase is dependent on external definitions. It's fairly likely
that the plan cache cannot safely use any upstream representation later
than the "raw parse tree" that's output by gram.y. You could make a
good case that we just ought to save query text and start from there in
any replanning; it'd be the most compact representation, the easiest to
copy around, and the least likely to break.
Which of course calls into question whether your current thoughts about
making the planner read-only are really going to advance the plan
caching project at all.
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
