Обсуждение: query very slow but table very small

Hi,

I have a table containing 8 rows. The records are around 2k max.
selects on this table take very long to complete:
This is not a table that had a lot of adds/deletes, and I
have run vacuum and analyze.

tium=# select count(*) from trunk;
  count
-------
      8
(1 row)

(Takes about 2 seconds)

The database is lightly loaded otherwise, but I don't understand
the explain output:

tium=# explain select count(*) from trunk;
                           QUERY PLAN
---------------------------------------------------------------
  Aggregate  (cost=65598.10..65598.11 rows=1 width=0)
    ->  Seq Scan on trunk  (cost=0.00..65598.08 rows=8 width=0)
(2 rows)

What does it mean that the cost figures are so high?

This is a standard run-of-the-mill server by the way with 1GB RAM,
I have shared buffers set to 12000.

Thanks,
Ron

--
NeoNova BV, The Netherlands
Professional internet and VoIP solutions

http://www.neonova.nl   Kruislaan 419              1098 VA Amsterdam
info: 020-5628292       servicedesk: 020-5628292   fax: 020-5628291
KvK Amsterdam 34151241

The following disclaimer applies to this email:
http://www.neonova.nl/maildisclaimer

am  Tue, dem 27.05.2008, um 11:31:47 +0200 mailte Ron Arts folgendes:
> Hi,
>
> I have a table containing 8 rows. The records are around 2k max.
> selects on this table take very long to complete:
> This is not a table that had a lot of adds/deletes, and I

How many UPDATE?


> have run vacuum and analyze.
>
> tium=# select count(*) from trunk;
>  count
> -------
>      8
> (1 row)
>
> (Takes about 2 seconds)

How big ist the table on disk? (pg_tablespace_size(name))


>
> The database is lightly loaded otherwise, but I don't understand
> the explain output:
>
> tium=# explain select count(*) from trunk;
>                           QUERY PLAN
> ---------------------------------------------------------------
>  Aggregate  (cost=65598.10..65598.11 rows=1 width=0)
>    ->  Seq Scan on trunk  (cost=0.00..65598.08 rows=8 width=0)
> (2 rows)
>
> What does it mean that the cost figures are so high?

wild guess: many updates on the table -> many dead rows. The cost
estimate are close to the real cost, the table is big on disk.


Andreas
--
Andreas Kretschmer
Kontakt:  Heynitz: 035242/47150,   D1: 0160/7141639 (mehr: -> Header)
GnuPG-ID:   0x3FFF606C, privat 0x7F4584DA   http://wwwkeys.de.pgp.net