Re: [HACKERS] wrong query plan in 7.1beta3
От | Peter Eisentraut |
---|---|
Тема | Re: [HACKERS] wrong query plan in 7.1beta3 |
Дата | |
Msg-id | Pine.LNX.4.30.0101271543400.1492-100000@peter.localdomain обсуждение исходный текст |
Ответ на | wrong query plan in 7.1beta3 (Kovacs Zoltan <kovacsz@pc10.radnoti-szeged.sulinet.hu>) |
Ответы |
Re: [HACKERS] wrong query plan in 7.1beta3
|
Список | pgsql-sql |
Kovacs Zoltan writes: > There seems to be an optimizer problem in 7.1beta3. The query you can see > below worked fast in 7.0.2 but in 7.1beta3 is rather slow. The problem is > that an 'index scan' has been changed to a 'seq scan'. Details: > Subquery Scan sd_user_grant (cost=38.68..38.85 rows=1 width=61) > -> Aggregate (cost=38.68..38.85 rows=1 width=61) > -> Group (cost=38.68..38.73 rows=10 width=61) > -> Sort (cost=38.68..38.68 rows=10 width=61) > -> Nested Loop (cost=0.00..38.51 rows=10 width=61) > -> Seq Scan on pg_shadow (cost=0.00..1.01 rows=1 width=32) > -> Seq Scan on sd_grant (cost=0.00..20.00 rows=1000 width=29) You haven't VACUUM ANALYZE'd the sd_grant table. Therefore the row estimate is way off (1000 vs 6) and thus a sequential scan is (correctly) thought to be faster. -- Peter Eisentraut peter_e@gmx.net http://yi.org/peter-e/
В списке pgsql-sql по дате отправления: