Tom Lane wrote:
> 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.
Hmm, I suppose that's true -- I had in mind that we would track
dependencies with sufficient granularity that we would know when
invoking each of those modules is necessary. For example, when a rule is
added to the database that affects one of the dependent tables of a
plan, we needn't rerun the parser or the analyzer.
But on reflection I think you're right -- the scheme above doesn't
really buy us much, and it is much simpler to just start with the query
string or raw parsetree whenever we need to recreate an invalidate plan.
Plus the above scheme might lead to some subtle bugs.
> 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.
True, but I've crossed the Rubicon already :) (Actually, I might stop
after I've introduced the QueryState struct and moved planner-internal
fields out of Query -- that will at least be a significant step closer
to the goal.)
-Neil