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
Views: Raw Message | Whole Thread | Download mbox | Resend email
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

Browse pgsql-hackers by date

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