Speedups

Поиск
Список
Период
Сортировка
От jwieck@debis.com (Jan Wieck)
Тема Speedups
Дата
Msg-id m0yAGK0-000BFRC@orion.SAPserv.Hamburg.dsh.de
обсуждение исходный текст
Ответы Re: [HACKERS] Speedups  (Bruce Momjian <maillist@candle.pha.pa.us>)
Re: [HACKERS] Speedups  (ocie@paracel.com)
Список 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@debis.com (Jan Wieck) #

В списке pgsql-hackers по дате отправления:

Предыдущее
От: jwieck@debis.com (Jan Wieck)
Дата:
Сообщение: Re: [HACKERS] Lost a function overloading capability in v6.3
Следующее
От: "Thomas G. Lockhart"
Дата:
Сообщение: Re: Glibc2 (was Re: [HACKERS] PostgreSQL - the Linux of Databases...)