Re: Query too slow
От | Bruce Momjian |
---|---|
Тема | Re: Query too slow |
Дата | |
Msg-id | 200309102015.h8AKF1Q10151@candle.pha.pa.us обсуждение исходный текст |
Ответ на | Re: Query too slow (Bruce Momjian <pgman@candle.pha.pa.us>) |
Список | pgsql-performance |
Bruce Momjian wrote: > Tom Lane wrote: > > Stephan Szabo <sszabo@megazone.bigpanda.com> writes: > > > On Tue, 26 Aug 2003, Ang Chin Han wrote: > > >> Veering aside a bit, since we usually pinpoint performance problems by > > >> looking at EXPLAIN ANALYZE's differences between the planner's > > >> estimation and actual execution's stats, what's involved in parsing the > > >> EXPLAIN ANALYZE results, and highlighting the places where they are way > > >> different? Bold, underline, or put some asterisks in front of those steps. > > > > > The hardest part is determining where it matters I think. You can use the > > > row counts as the base for that, but going from 1 row to 50 is not > > > necessarily going to be an issue, but it might be if a nested loop is > > > chosen. > > > > We've been chatting about this idea among the Red Hat group. The RHDB > > Visual Explain tool (get it at http://sources.redhat.com/rhdb/) already > > computes the percent of total runtime represented by each plan node. > > It seems like we could highlight nodes based on a large difference > > between estimated and actual percentage, or just highlight the nodes > > that are more than X percent of the runtime. > > Is there a TODO here? Perhaps: > > o Have EXPLAIN ANALYZE highlight poor optimizer estimates No one commented, so I had to guess --- I added it. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073
В списке pgsql-performance по дате отправления: