On Fri, Dec 13, 2002 at 04:41:38PM +0100, Thomas Beutin wrote:
> itb=# EXPLAIN ANALYZE SELECT COUNT(DISTINCT a_id) FROM stat_pages WHERE m_id = 35::smallint AND (visit >=
'2002-10-01'AND visit <= '2002-10-31');
> NOTICE: QUERY PLAN:
>
> Aggregate (cost=8788.75..8788.75 rows=1 width=34) (actual time=4663.69..4663.70 rows=1 loops=1)
> -> Index Scan using tb5 on stat_pages (cost=0.00..8712.60 rows=30459 width=34) (actual time=0.41..468.35
rows=29937loops=1)
> Total runtime: 4663.99 msec
Now this catched my attention (in the questions' side, sorry, not the
answers'). Why the aggregate takes 10 times the time needed for the
indexscan? One would think that a function like count() should be
pretty cheap, and the planner seems to think so (total cost for the
Aggregate node is about the same as total cost for IndexScan node), but
the executor has a completely different view...
Can that be a cut'n paste error?
--
Alvaro Herrera (<alvherre[a]dcc.uchile.cl>)
"¿Qué importan los años? Lo que realmente importa es comprobar que
a fin de cuentas la mejor edad de la vida es estar vivo" (Mafalda)