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.


Jan

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#======================================== jwieck(at)debis(dot)com (Jan Wieck) #

Responses

• Re: [HACKERS] Speedups at 1998-03-04 16:30:10 from Bruce Momjian
• Re: [HACKERS] Speedups at 1998-03-04 18:57:05 from ocie

pgsql-hackers by date

Next:	From: Thomas G. Lockhart	Date: 1998-03-04 15:48:01
	Subject: Re: Glibc2 (was Re: [HACKERS] PostgreSQL - the Linux of Databases...)
Previous:	From: Jan Wieck	Date: 1998-03-04 15:10:19
	Subject: Re: [HACKERS] Lost a function overloading capability in v6.3