Re: performance question

Reinoud van Leeuwen <reinoud@xs4all.nl>

From: "Reinoud van Leeuwen" <reinoud@xs4all.nl>
To: <pgsql-hackers@postgresql.org>
Date: 2001-08-28T13:09:06Z
Lists: 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