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

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

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: EXPLAIN (plan off, rewrite off) for benchmarking
Date: 2011-11-21 19:05:54
Message-ID: CA+Tgmob-QwGxQwykSw3aaVp+rQ9zRNN4hz_ZB5M0D5YKrJ7zYA@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-hackers
On Sat, Nov 19, 2011 at 11:47 AM, Andres Freund <andres(at)anarazel(dot)de> wrote:
> I absolutely cannot agree on the fact that the speed parse-analyze is
> irrelevant though.

Tom may be right that the speed of the parser *in isolation* is
irrelevant, in the narrow sense that if we made the parser twice as
slow but somehow by that change made up the time in the executor,
nobody would care; in fact, it would be a net win for people using
prepared statements.  But I completely agree that parsing speed is
something we need to worry about.  Unfortunately, I don't have a lot
of good ideas for improving it.  A while back I tried ripping out most
of the parser to see whether that would speed up performance parsing
very simple statements, but the improvement was pretty small.  Maybe a
more thorough job than what I did is possible, but it didn't seem
promising.  Maybe we could find a way to reduce the size of the parse
tree (i.e. fewer nodes), or the number of times that it has to be
walked/copied.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Responses

pgsql-hackers by date

Next:From: Robert HaasDate: 2011-11-21 19:19:24
Subject: Re: RFC: list API / memory allocations
Previous:From: Robert HaasDate: 2011-11-21 18:49:21
Subject: Re: proposal: better support for debugging of overloaded functions

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