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

Re: [HACKERS] Speedups

From: ocie(at)paracel(dot)com
To: jwieck(at)debis(dot)com
Cc: pgsql-hackers(at)postgreSQL(dot)org
Subject: Re: [HACKERS] Speedups
Date: 1998-03-04 18:57:05
Message-ID: 9803041857.AA25703@dolomite.paracel.com (view raw or flat)
Thread:
Lists: pgsql-hackers
Jan Wieck wrote:
> 
> Hi,
> 
>     just to let anyone know:
> 
>     I  did  some analyzing and searched for areas that could gain
>     more speedups  for  6.4.   First  I  had  something  like  an
>     optimizer cache in mind (planner remembers parsetree and if a
>     subsequent parsetree only differs in const values, substitute
>     consts  by params and reuse saved plans instead of creating a
>     new plan all the time).
> 
>     But this is what I got for the complete regression test (only
>     queries that went through the planner counted):
> 
>         Parsing and rule rewriting    14 %
>         Optimizer and planning         6 %
>         Query execution               80 %
>                                     ------
>         Total time in backend        100 %
> 
>     It  clearly  shows  that  there's  no  need  to  speedup  the
>     optimizer.  The parser and the executor  are  the  ones  that
>     consume  the  time.   Making  the  planner/optimizer  smarter
>     resulting better plans faster to execute is the way.

This may sound like an obvious question, but if a user defines a
query, do we save the query plan?  This would reduce the
communications between the client and server (a small gain), and allow
the server to start executing the query as soon as it recognized the
name of the stored query and parsed the arguments.

Ocie Mitchell


In response to

  • Speedups at 1998-03-04 15:43:03 from Jan Wieck

Responses

pgsql-hackers by date

Next:From: Ponomarev S.Date: 1998-03-04 19:50:31
Subject:
Previous:From: Bruce MomjianDate: 1998-03-04 18:27:06
Subject: Re: [QUESTIONS] Problems with running v6.3 on DIGITAL UNIX

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