Re: read-only planner input

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Neil Conway <neilc(at)samurai(dot)com>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: read-only planner input
Date: 2005-03-18 06:55:38
Message-ID: 3723.1111128938@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Neil Conway <neilc(at)samurai(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Neil Conway 2005-03-18 07:23:03 Re: read-only planner input
Previous Message Tom Lane 2005-03-18 06:47:47 Re: read-only planner input