From: Andreas Joseph Krogh <andreak@officenet.no>
To: Richard Huxton <dev@archonet.com>
Cc: pgsql-sql@postgresql.org
Subject: Re: Very low performance on table with only 298 rows
Date: Thu, 14 Apr 2005 13:53:12 +0200
Message-ID: <200504141353.14022.andreak@officenet.no> (raw)
In-Reply-To: <425E53C7.5080604@archonet.com>
References: <200504141248.21783.andreak@officenet.no>
<425E53C7.5080604@archonet.com>
On Thursday 14 April 2005 13:28, Richard Huxton wrote:
> Andreas Joseph Krogh wrote:
> > nbeweb=> EXPLAIN select count(*) from onp_web_index;
> > QUERY PLAN
> > -------------------------------------------------------------------------
> >---- Hi all.
> > I have a problem with a table which only has 298 rows in it. A select
> > count(*) takes forever and CTRL-C also takes a long time canceling the
> > query. There are only 298 rows in the table when count(*) returns. How
> > come it takes such a long time counting only 298 rows? Here is EXPLAIN
> > ANALYZE:
> >
> > nbeweb=> EXPLAIN ANALYZE select count(*) from onp_web_index;
> > QUERY PLAN
> > -------------------------------------------------------------------------
> >---------------------------------------------------------- Aggregate
> > (cost=205759.52..205759.52 rows=1 width=0) (actual
> > time=179748.910..179748.913 rows=1 loops=1)
> > -> Seq Scan on onp_web_index (cost=0.00..205455.41 rows=121641
> > width=0) (actual time=179735.956..179747.821 rows=298 loops=1)
> > Total runtime: 179748.993 ms
>
> Why does PG think you have 121641 rows in this table?
> How often do you vacuum it?
> How often do you analyse it?
> Does "vacuum full verbose" show a lot of dead rows being removed?
>
> I'm suspecting a *lot* of dead rows need to be removed.
I vacuum the whole database every sunday with the command:
VACUUM ANALYZE
Do I need to issue a VACUUM FULL? I've never VACUUM FULL'ed it..
I have other much larger tables which take lot less time to count(*). Cant it
be that this table is hosed somehow? Note: I have a column of type tsvector
in there, cat it be that this column causes some unexpected trouble?
I'm issuing a VACUUM FULL verbose now...
--
Andreas Joseph Krogh <andreak@officenet.no>
Senior Software Developer / Manager
gpg public_key: http://dev.officenet.no/~andreak/public_key.asc
------------------------+---------------------------------------------+
OfficeNet AS | The most difficult thing in the world is to |
Hoffsveien 17 | know how to do a thing and to watch |
PO. Box 425 Skøyen | somebody else doing it wrong, without |
0213 Oslo | comment. |
NORWAY | |
Phone : +47 22 13 01 00 | |
Direct: +47 22 13 10 03 | |
Mobile: +47 909 56 963 | |
------------------------+---------------------------------------------+
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-sql@postgresql.org
Cc: andreak@officenet.no, dev@archonet.com
Subject: Re: Very low performance on table with only 298 rows
In-Reply-To: <200504141353.14022.andreak@officenet.no>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
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