From: | "A(dot) Kretschmer" <andreas(dot)kretschmer(at)schollglas(dot)com> |
---|---|
To: | pgsql-novice(at)postgresql(dot)org |
Subject: | Re: query very slow but table very small |
Date: | 2008-05-27 10:16:35 |
Message-ID: | 20080527101633.GC27604@a-kretschmer.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-novice |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Lee Hachadoorian | 2008-05-28 18:28:05 | Table and View Planning for Census Data |
Previous Message | Ron Arts | 2008-05-27 09:31:47 | query very slow but table very small |