Re: EXPLAIN (plan off, rewrite off) for benchmarking

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Mon, Nov 21, 2011 at 8:54 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> We could eliminate some annoying tree-copy steps if we could institute
>> the policy that parse analysis doesn't scribble on the raw parse tree,
>> rewriter doesn't modify parse analysis output, and planner doesn't
>> modify rewriter output.

> This is probably a stupid question, but why does it matter if parse
> analysis scribbles on the raw parse tree, or the rewriter on the parse
> analysis output?

Because we frequently need to save the original tree for possible
re-analysis later. This doesn't matter in the simple-query protocol,
but it does matter in any code path that involves plancache.

> I understand that we may sometimes need to replan
> the output of the rewriter, so we'd better not modify it
> destructively, but I would have thought that parse and parse analysis
> would always be done together, in which case it doesn't obviously
> matter.

No, actually it's the raw grammar output tree that gets saved for
re-analysis in case we are told of a DDL change. (I've considered
having the code save only the original query string, but then you'd
have to repeat the flex/bison work, and those things show up high
enough on any profile to make it seem unlikely that this is cheaper
than copying the parse tree.)

It's possible that we don't need a read-only guarantee for the rewriter
versus parse analysis output, but I doubt that helps much.

regards, tom lane