Re: Long count(*) time

I'm a newbie in databases but maybe this is useful :
"Triggers can be defined to execute either before or after any INSERT, UPDATE, or DELETE operation, either once per modified row, or once per SQL statement. If a trigger event occurs, the trigger's function is called at the appropriate time to handle the event."
(from : http://www.postgresql.org/docs/8.1/interactive/triggers.html)
If you run this query a lot of times, it might be useful to write such a procedure that on every insert increases the number and on every delete decreases the number which you can store in a separate table. Of course usability depends on the number of insert/delete queries performed because the count query will go to milliseconds but every insert/delete will take (no idea how much) longer.

Michael



David Monarchi <david.e.monarchi@gmail.com> wrote:

Hello -

I'm running PG 8.2 on an 8-processor 16G Unix machine.  The machine is dedicated to the db, and only 5 threads/processors are busy.  The following query takes 70 seconds to execute. 
     select count(*) from url_list_url;
There are 64,219,173 rows in the table.  The table consists of an integer field and a text field.  The average length of the text field is 50 characters.  There are btree indexes on both fields.  The integer field is the key.

70 seconds seems to be a long time for this kind of query.  Is this normal?

Thanks.

David

---

Luggage? GPS? Comic books?
Check out fitting gifts for grads at Yahoo! Search.