Re: read-only planner input - Mailing list pgsql-hackers

From Tom Lane
Subject Re: read-only planner input
Date
Msg-id 3723.1111128938@sss.pgh.pa.us
Whole thread Raw
In response to read-only planner input  (Neil Conway <neilc@samurai.com>)
Responses Re: read-only planner input  (Neil Conway <neilc@samurai.com>)
Re: read-only planner input  (Oliver Jowett <oliver@opencloud.com>)
List 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 by date:

Previous
From: Tom Lane
Date:
Subject: Re: read-only planner input
Next
From: Neil Conway
Date:
Subject: Re: read-only planner input