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

Speedups

From: jwieck(at)debis(dot)com (Jan Wieck)
To: pgsql-hackers(at)postgreSQL(dot)org (PostgreSQL HACKERS)
Subject: Speedups
Date: 1998-03-04 15:43:03
Message-ID: m0yAGK0-000BFRC@orion.SAPserv.Hamburg.dsh.de (view raw or flat)
Thread:
Lists: pgsql-hackers
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

pgsql-hackers by date

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

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