From: | "Reinoud van Leeuwen" <reinoud(at)xs4all(dot)nl> |
---|---|
To: | <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: performance question |
Date: | 2001-08-28 13:09:06 |
Message-ID: | 18813.194.109.0.126.999004146.squirrel@webmail.xs4all.nl |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Bruno Mattarollo | 2001-08-28 14:17:00 | Re: 7.1.3, IRIX 6.5 and gcc |
Previous Message | Alex Pilosov | 2001-08-28 13:08:01 | Re: Toast,bytea, Text -blob all confusing |