pg.ddx.io pgsql-docs@postgresql.org mailing list archive
help / color / mirror / Atom feedstrange query plan
2+ messages / 2 participants
[nested] [flat]
* strange query plan
@ 2001-04-08 08:35 Mario Weilguni <mweilguni@sime.com>
0 siblings, 1 reply; 2+ messages in thread
From: Mario Weilguni @ 2001-04-08 08:35 UTC (permalink / raw)
To: pgsql-general@postgresql.org
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
===================================================
^ permalink raw reply [nested|flat] 2+ messages in thread
* Re: strange query plan
@ 2001-04-08 11:50 Peter Eisentraut <peter_e@gmx.net>
parent: Mario Weilguni <mweilguni@sime.com>
0 siblings, 0 replies; 2+ messages in thread
From: Peter Eisentraut @ 2001-04-08 11:50 UTC (permalink / raw)
To: Mario Weilguni <mweilguni@sime.com>; +Cc: pgsql-general@postgresql.org
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/
^ permalink raw reply [nested|flat] 2+ messages in thread
end of thread, other threads:[~2001-04-08 11:50 UTC | newest]
Thread overview: 2+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2001-04-08 08:35 strange query plan Mario Weilguni <mweilguni@sime.com>
2001-04-08 11:50 ` Peter Eisentraut <peter_e@gmx.net>
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox