Re: read-only planner input
От | Tom Lane |
---|---|
Тема | Re: read-only planner input |
Дата | |
Msg-id | 3723.1111128938@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | read-only planner input (Neil Conway <neilc@samurai.com>) |
Ответы |
Re: read-only planner input
Re: read-only planner input |
Список | pgsql-hackers |
Neil Conway <neilc@samurai.com> 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
В списке pgsql-hackers по дате отправления: