Re: Query Plan far worse in 7.3.2 than 7.2.1
От | SZŰCS Gábor |
---|---|
Тема | Re: Query Plan far worse in 7.3.2 than 7.2.1 |
Дата | |
Msg-id | 004401c30f07$c07f45e0$0a03a8c0@fejleszt2 обсуждение исходный текст |
Ответ на | Query Plan far worse in 7.3.2 than 7.2.1 ("SZŰCS Gábor" <surrano@mailbox.hu>) |
Список | pgsql-performance |
----- Original Message ----- From: "Tom Lane" <tgl@sss.pgh.pa.us> Sent: Wednesday, April 30, 2003 1:05 AM > "=?iso-8859-2?B?U1rbQ1MgR+Fib3I=?=" <surrano@mailbox.hu> writes: > > ---------------------------- 7.2.1 PLAN --------------------------------- > > -> Seq Scan on valuta (cost=0.00..1.06 rows=6 width=4) (actual time=0.02..0.11 rows=6 loops=2) > > > > ---------------------------- 7.3.2 PLAN --------------------------------- > > -> Seq Scan on valuta (cost=0.00..20.00 rows=1000 width=4) (actual time=0.02..0.06 rows=6 loops=2) > > Ah, there's the problem. You never vacuumed or analyzed "valuta", so > the 7.3 planner didn't know it had only six rows, and chose a plan that > was more appropriate for a larger table. The thousand-row estimate is > the tipoff, because that's the default assumption when there are no > stats. > > regards, tom lane Thanks! VACUUM ANALYZE really worked and I learned something new. The strange part is, that I think I issued a "VACUUM ANALYZE;" (that should do all the tables, right?) a couple of weeks before because of another problem (it didn't help that time, tho) G. -- while (!asleep()) sheep++; ---------------------------- cut here ------------------------------
В списке pgsql-performance по дате отправления: