| From: | Sailesh Krishnamurthy <sailesh(at)cs(dot)berkeley(dot)edu> |
|---|---|
| To: | Neil Conway <neilc(at)samurai(dot)com> |
| Cc: | PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: detecting poor query plans |
| Date: | 2003-11-26 15:59:58 |
| Message-ID: | bxyznejp1c1.fsf@datafix.cs.berkeley.edu |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
>>>>> "Neil" == Neil Conway <neilc(at)samurai(dot)com> writes:
Neil> It occurred to me that these kinds of poor planning
Neil> decisions could easily be detected by PostgreSQL itself:
Neil> after we've finished executing a plan, we can trivially
Neil> compare the # of results produced by each node in the query
Neil> tree with the # of results the planner expected that node to
Neil> produce (look at EXPLAIN ANALYZE, for example). If the
Indeed. This is the approach being followed by the LeO project
(Learning Optimizer) at IBM Almaden.
http://www.almaden.ibm.com/software/dm/SMART/leo.shtml
There is a vldb paper that describes it ..
--
Pip-pip
Sailesh
http://www.cs.berkeley.edu/~sailesh
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2003-11-26 16:00:01 | Re: detecting poor query plans |
| Previous Message | Peter Eisentraut | 2003-11-26 15:58:56 | NetBSD Sparc OK |