pg.ddx.io pgsql-sql@postgresql.org mailing list archive
help / color / mirror / Atom feedVery low performance on table with only 298 rows
4+ messages / 3 participants
[nested] [flat]
* Very low performance on table with only 298 rows
@ 2005-04-14 10:48 Andreas Joseph Krogh <andreak@officenet.no>
0 siblings, 2 replies; 4+ messages in thread
From: Andreas Joseph Krogh @ 2005-04-14 10:48 UTC (permalink / raw)
To: pgsql-sql
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
(3 rows)
Here is the schema:
nbeweb=> \d onp_web_index;
Table "public.onp_web_index"
Column | Type | Modifiers
-------------+-------------------+---------------------------------------------------------------
id | integer | not null default
nextval('public.onp_web_index_id_seq'::text)
starturl_id | integer | not null
lang_id | integer | not null
url_host | character varying | not null
url_path | character varying | not null
title | character varying | not null
content | tsvector | not null
plain_text | character varying | not null
Indexes:
"onp_web_index_pkey" primary key, btree (id)
"onp_web_index_url_host_key" unique, btree (url_host, url_path)
"onp_web_index_idx" gist (content)
Foreign-key constraints:
"$2" FOREIGN KEY (lang_id) REFERENCES code(id)
"$1" FOREIGN KEY (starturl_id) REFERENCES onp_web_index_starturl(id) ON
DELETE CASCADE
Any hints on how I can "fix" this lousy performance?
--
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 | |
------------------------+---------------------------------------------+
^ permalink raw reply [nested|flat] 4+ messages in thread
* Re: Very low performance on table with only 298 rows
@ 2005-04-14 11:28 Richard Huxton <dev@archonet.com>
parent: Andreas Joseph Krogh <andreak@officenet.no>
1 sibling, 1 reply; 4+ messages in thread
From: Richard Huxton @ 2005-04-14 11:28 UTC (permalink / raw)
To: Andreas Joseph Krogh <andreak@officenet.no>; +Cc: pgsql-sql
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.
--
Richard Huxton
Archonet Ltd
^ permalink raw reply [nested|flat] 4+ messages in thread
* Re: Very low performance on table with only 298 rows
@ 2005-04-14 11:53 Andreas Joseph Krogh <andreak@officenet.no>
parent: Richard Huxton <dev@archonet.com>
0 siblings, 0 replies; 4+ messages in thread
From: Andreas Joseph Krogh @ 2005-04-14 11:53 UTC (permalink / raw)
To: Richard Huxton <dev@archonet.com>; +Cc: pgsql-sql
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 | |
------------------------+---------------------------------------------+
^ permalink raw reply [nested|flat] 4+ messages in thread
* Re: Very low performance on table with only 298 rows
@ 2005-04-14 17:08 PFC <lists@boutiquenumerique.com>
parent: Andreas Joseph Krogh <andreak@officenet.no>
1 sibling, 0 replies; 4+ messages in thread
From: PFC @ 2005-04-14 17:08 UTC (permalink / raw)
To: Andreas Joseph Krogh <andreak@officenet.no>; pgsql-sql
> nbeweb=> EXPLAIN ANALYZE select count(*) from onp_web_index;
> Total runtime: 179748.993 ms
WOW.
It's possible your table is bloated.
What version of PG are you using ?
VACUUM FULL ANALYZE VERBOSE onp_web_index
if it solves your problem, good, else post the results from that command.
^ permalink raw reply [nested|flat] 4+ messages in thread
end of thread, other threads:[~2005-04-14 17:08 UTC | newest]
Thread overview: 4+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2005-04-14 10:48 Very low performance on table with only 298 rows Andreas Joseph Krogh <andreak@officenet.no>
2005-04-14 11:28 ` Richard Huxton <dev@archonet.com>
2005-04-14 11:53 ` Andreas Joseph Krogh <andreak@officenet.no>
2005-04-14 17:08 ` PFC <lists@boutiquenumerique.com>
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