Skip site navigation (1) Skip section navigation (2)

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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Andres Freund <andres(at)anarazel(dot)de>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: EXPLAIN (plan off, rewrite off) for benchmarking
Date: 2011-11-22 15:18:15
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
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

In response to

pgsql-hackers by date

Next:From: Jeff DavisDate: 2011-11-22 16:53:41
Subject: Re: Singleton range constructors versus functional coercion notation
Previous:From: Robert HaasDate: 2011-11-22 14:36:18
Subject: Re: EXPLAIN (plan off, rewrite off) for benchmarking

Privacy Policy | About PostgreSQL
Copyright © 1996-2018 The PostgreSQL Global Development Group