Обсуждение: Slow select, insert, update

Having trouble with one table (see time to count records below!).


Fairly new to postgres so any help much appreciated.


It only contains 9,106 records - as you can see from:



select count(id) from project


<bold><fontfamily><param>Arial</param><x-tad-bigger>count</x-tad-bigger><x-tad-bigger>

</x-tad-bigger></fontfamily></bold><fontfamily><param>Arial</param><x-tad-bigger>9106

1 row(s)

Total runtime: 45,778.813 ms



There are only 3 fields:


id

integer

nextval('id'::text)


projectnumber

text


description

text



There is one index:


id_project_ukey

CREATE UNIQUE INDEX id_project_ukey ON project USING btree (id)


... the database is regularly vaccuumed.</x-tad-bigger></fontfamily>
Having trouble with one table (see time to count records below!).

Fairly new to postgres so any help much appreciated.

It only contains 9,106 records - as you can see from:


select count(id) from project

count
9106
1 row(s)
Total runtime: 45,778.813 ms


There are only 3 fields:

id
integer
nextval('id'::text)

projectnumber
text

description
text


There is one index:

id_project_ukey
CREATE UNIQUE INDEX id_project_ukey ON project USING btree (id)

... the database is regularly vaccuumed.

Paul Langard <pjl@intercellsolutions.com> writes:

> Having trouble with one table (see time to count records below!).
>
> Fairly new to postgres so any help much appreciated.
>
> It only contains 9,106 records - as you can see from:
>
>
> select count(id) from project
>
> count
> 9106
> 1 row(s)
> Total runtime: 45,778.813 ms

> ... the database is regularly vaccuumed.

Hmm.  You might try a VACUUM FULL and a REINDEX on the table (you
don't say what version you are running--REINDEX is sometimes needed on
7.3 and below).

Also, use EXPLAIN ANALYZE on your query and post the result--that's
helpful diagnostic information.

-Doug
--
Let us cross over the river, and rest under the shade of the trees.
   --T. J. Jackson, 1863

Paul,

Paul Langard wrote:

> Having trouble with one table (see time to count records below!).
>
> Fairly new to postgres so any help much appreciated.
>
> It only contains 9,106 records - as you can see from:
>
>
> select count(id) from project
>
> *count
> *9106
> 1 row(s)
> Total runtime: 45,778.813 ms

<snip>

> ... the database is regularly vaccuumed.


Have you tried doing a VACUUM FULL, CLUSTER, or drop/restore on the
table? This sounds symptomatic of a table with a bunch of dead tuples
not in the FSM (free space map). Only tuples in the FSM are reclaimed by
a regular VACUUM. If your FSM parameters in postgresql.conf are not big
enough for your ratio of UPDATE/DELETE operations to VACUUM frequency,
you will end up with dead tuples that will only be reclaimed by a VACUUM
FULL.

To prevent this problem in the future, look at increasing your FSM size
and possibly vacuuming more frequently or using pg_autovacuum.

Good Luck,

Bill Montgomery

Paul Langard <pjl@intercellsolutions.com> writes:
> select count(id) from project
> count
> 9106
> 1 row(s)
> Total runtime: 45,778.813 ms

Yipes.  The only explanation I can think of is tremendous table bloat.
What do you get from "vacuum verbose project" --- in particular, how
many pages in the table?

> ... the database is regularly vaccuumed.

Not regularly enough, perhaps ... or else you need to increase the free
space map size parameters.  In any case you'll probably need to do one
round of "vacuum full" to get this table back within bounds.

            regards, tom lane

Does that mean reindex is not needed
for PG version 7.4?

In what kind situations under PG 7.4,
reindex is worthwhile?

Thanks,


Here is doc from 7.3:
PostgreSQL is unable to reuse B-tree index pages in
certain cases. The problem is that if indexed rows are
deleted, those index pages can only be reused by rows
with similar values. For example, if indexed rows are
deleted and newly inserted/updated rows have much
higher values, the new rows can't use the index space
made available by the deleted rows. Instead, such new
rows must be placed on new index pages. In such cases,
disk space used by the index will grow indefinitely,
even if VACUUM is run frequently.

As a solution, you can use the REINDEX command
periodically to discard pages used by deleted rows.
There is also contrib/reindexdb which can reindex an
entire database.

The counterpart of 7.4 is:
In some situations it is worthwhile to rebuild indexes
periodically with the REINDEX command. (There is also
contrib/reindexdb which can reindex an entire
database.) However, PostgreSQL 7.4 has substantially
reduced the need for this activity compared to earlier
releases.


--- Doug McNaught <doug@mcnaught.org> wrote:

> Paul Langard <pjl@intercellsolutions.com> writes:
>
> > Having trouble with one table (see time to count
> records below!).
> >
> > Fairly new to postgres so any help much
> appreciated.
> >
> > It only contains 9,106 records - as you can see
> from:
> >
> >
> > select count(id) from project
> >
> > count
> > 9106
> > 1 row(s)
> > Total runtime: 45,778.813 ms
>
> > ... the database is regularly vaccuumed.
>
> Hmm.  You might try a VACUUM FULL and a REINDEX on
> the table (you
> don't say what version you are running--REINDEX is
> sometimes needed on
> 7.3 and below).
>
> Also, use EXPLAIN ANALYZE on your query and post the
> result--that's
> helpful diagnostic information.
>
> -Doug
> --
> Let us cross over the river, and rest under the
> shade of the trees.
>    --T. J. Jackson, 1863
>
>
> ---------------------------(end of
> broadcast)---------------------------
> TIP 8: explain analyze is your friend
>




__________________________________
Do you Yahoo!?
Read only the mail you want - Yahoo! Mail SpamGuard.
http://promotions.yahoo.com/new_mail