Re: select count(*) very slow on an already vacuumed table.

The relation size for this table is 1.7 GB

tradein_clients=# SELECT public.relation_size ('general.rfis');
+------------------+
| relation_size |
+------------------+
| 1,762,639,872 |
+------------------+
(1 row)

Regds
mallah.

Rajesh Kumar Mallah wrote:

>
>
> 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"?
>>
>>
>>
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 2: you can get off all lists at once with the unregister command
> (send "unregister YourEmailAddressHere" to majordomo(at)postgresql(dot)org)
>