Re: Slow query
От | scott.marlowe |
---|---|
Тема | Re: Slow query |
Дата | |
Msg-id | Pine.LNX.4.33.0403010923120.32148-100000@css120.ihs.com обсуждение исходный текст |
Ответ на | Slow query (Ivan Voras <ivoras@fer.hr>) |
Список | pgsql-performance |
On Tue, 24 Feb 2004, Ivan Voras wrote: > -> Nested Loop (cost=1.04..788.76 rows=3 width=500) (actual > time=4078.85..20185.89 rows=38999 loops=1) > -> Nested Loop (cost=1.04..771.27 rows=3 width=485) > (actual time=4078.71..14673.27 rows=38999 loops=1) > -> Nested Loop (cost=0.00..752.16 rows=195 > width=288) (actual time=4078.20..6702.17 rows=38999 loops=1) > -> Nested Loop > (cost=0.00..748.72 rows=195 width=184) (actual time=0.21..3197.16 > rows=38999 loops=1) Note those nested loops up there. They think that you are going to be operating on 3,3,195, and 195 rows respectively, when they actually are operating on 38999, 38999, 38999, and 38999 in reality. set enable_nestloop = off and see if that helps. If so, see if altering the responsible columns default stats to something higher (100 is a good start) and reanalyze to see if you get a better plan. As long as those estimates are that far off, you're gonna get a poorly performing query when the planner is allowed to use nested loops.
В списке pgsql-performance по дате отправления: