Обсуждение: strange query plan

I've a table containing some sort of logs, the table layout ist:
 Attribute |           Type           |               Modifier
-----------+--------------------------+---------------------------------------
 id        | integer                  | not null default nextval('ids'::text)
 serverid  | integer                  | not null
 ts        | timestamp with time zone | default now()
 log       | character varying(400)   | not null
Indices: i1,
         log_pkey

primary key is id, and there is an additional index on serverid. The table
contains ~ 1.4 mio of rows, I've used "vacuum analyze".

Now when I type:
explain select min(id)from log;
NOTICE:  QUERY PLAN:

Aggregate  (cost=45702.20..45702.20 rows=1 width=4)
  ->  Seq Scan on log  (cost=0.00..41978.36 rows=1489536 width=4)

I don't understand why the index log_pkey is not used here. I guess it would
be much cheaper to consult the index to get min(), max(), sum() and avg()
instead of sequentially scanning ~500MB of data.

Any idea?

Thanks

Best regards,
    Mario Weilguni


--
===================================================
 Mario Weilguni                               KPNQwest Austria GmbH
 Senior Engineer Web Solutions                         Nikolaiplatz 4
 tel: +43-316-813824                                8020 graz, austria
 fax: +43-316-813824-26                    http://www.kpnqwest.at
 e-mail: mario.weilguni@kpnqwest.com
===================================================

Mario Weilguni writes:

> Now when I type:
> explain select min(id)from log;
> NOTICE:  QUERY PLAN:
>
> Aggregate  (cost=45702.20..45702.20 rows=1 width=4)
>   ->  Seq Scan on log  (cost=0.00..41978.36 rows=1489536 width=4)
>
> I don't understand why the index log_pkey is not used here. I guess it would
> be much cheaper to consult the index to get min(), max(), sum() and avg()
> instead of sequentially scanning ~500MB of data.

Since your query reads the entire "log" table, it is certainly better to
use a sequential scan in the case of sum() and avg().  A min() and max()
would theoretically not need to scan the entire table in the presence of
an index, but unfortunately this doesn't work yet.

--
Peter Eisentraut      peter_e@gmx.net       http://yi.org/peter-e/