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
---------------------------(end of broadcast)--------------------------- TIP 6: Have you searched our list archives?
http://archives.postgresql.org
