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) #
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 |