Re: performance question
От | Reinoud van Leeuwen |
---|---|
Тема | Re: performance question |
Дата | |
Msg-id | 18813.194.109.0.126.999004146.squirrel@webmail.xs4all.nl обсуждение исходный текст |
Ответ на | Re: performance question (Stephan Szabo <sszabo@megazone23.bigpanda.com>) |
Список | pgsql-hackers |
> On Tue, 28 Aug 2001, Reinoud van Leeuwen wrote: > >> Can somebody explain to me: >> >> > radius=# explain select count (radiuspk) from radius ; >> > NOTICE: QUERY PLAN: >> > >> > Aggregate (cost=12839.79..12839.79 rows=1 width=8) >> > -> Seq Scan on radius (cost=0.00..11843.43 rows=398543 width=8) >> > >> > EXPLAIN >> >> >> This query answers me *instantly* after hitting return >> >> > radius=# select count (radiuspk) from radius ; >> > count >> > -------- >> > 398543 >> > (1 row) >> >> This query takes about 3 seconds. But the query plan *already* knows >> the number of rows ("rows=398543"). So why does it take 3 seconds. Is >> my assumption correct that the optimiser still can be optimized a >> little? :-) > > Not in this case. The row numbers from explain are just estimates > from the last vacuum. As you modify the table, the estimated rows will > be off. Yes, I just found out that somebody else is running a script on our test server that vacuums all databases each night. That explains a lot. Thanx for thinking with me Reinoud
В списке pgsql-hackers по дате отправления: