From: | Rajesh Kumar Mallah <mallah(at)trade-india(dot)com> |
---|---|
To: | Richard Huxton <dev(at)archonet(dot)com> |
Cc: | Postgres Performance <pgsql-performance(at)postgresql(dot)org> |
Subject: | Re: select count(*) very slow on an already vacuumed table. |
Date: | 2004-04-15 07:10:27 |
Message-ID: | 407E3563.6000408@trade-india.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
The problem is that i want to know if i need a Hardware upgrade
at the moment.
Eg i have another table rfis which contains ~ .6 million records.
SELECT count(*) from rfis where sender_uid > 0;
+--------+
| count |
+--------+
| 564870 |
+--------+
Time: 117560.635 ms
Which is approximate 4804 records per second. Is it an acceptable
performance on the hardware below:
RAM: 2 GB
DISKS: ultra160 , 10 K , 18 GB
Processor: 2* 2.0 Ghz Xeon
What kind of upgrades shoud be put on the server for it to become
reasonable fast.
Regds
mallah.
Richard Huxton wrote:
>On Wednesday 14 April 2004 18:53, Rajesh Kumar Mallah wrote:
>
>
>>Hi
>>I have .5 million rows in a table. My problem is select count(*) takes
>>ages. VACUUM FULL does not help. can anyone please tell me
>>how to i enhance the performance of the setup.
>>
>>
>
>
>
>>SELECT count(*) from eyp_rfi;
>>
>>
>
>If this is the actual query you're running, and you need a guaranteed accurate
>result, then you only have one option: write a trigger function to update a
>table_count table with every insert/delete to eyp_rfi.
>
>There is loads of info on this (and why it isn't as simple as you might think)
>in the archives. First though:
>1. Is this the actual query, or just a representation?
>2. Do you need an accurate figure or just something "near enough"?
>
>
>
From | Date | Subject | |
---|---|---|---|
Next Message | Rajesh Kumar Mallah | 2004-04-15 07:34:40 | Re: select count(*) very slow on an already vacuumed table. |
Previous Message | pginfo | 2004-04-15 06:03:18 | linux distro for better pg performance |