Re: [ SOLVED ] select count(*) very slow on an already

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: [ SOLVED ] select count(*) very slow on an already
Date: 2004-04-15 11:35:45
Message-ID: 407E7391.4060706@trade-india.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance


Hi,

The problem was solved by reloading the Table.
the query now takes only 3 seconds. But that is
not a solution.

The problem is that such phenomenon obscures our
judgement used in optimising queries and database.

If a query runs slow we really cant tell if its a problem
with query itself , hardware or dead rows.

I already did vacumm full on the table but it still did not
have that effect on performance.
In fact the last figures were after doing a vacuum full.

Can there be any more elegent solution to this problem.

Regds
Mallah.

Richard Huxton wrote:

>On Thursday 15 April 2004 08:10, 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;
>>
>>
>
>
>
>>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
>>
>>
>
>Hmm - doesn't seem good, does it? If you run it again, is it much faster
>(since the data should be cached then)? What does "vmstat 10" show while
>you're running the query?
>
>One thing you should have done is read the performance tuning guide at:
> http://www.varlena.com/varlena/GeneralBits/Tidbits/index.php
>The default values are very conservative, and you will need to change them.
>
>
>
>>What kind of upgrades shoud be put on the server for it to become
>>reasonable fast.
>>
>>
>
>If you've only got one disk, then a second disk for OS/logging. Difficult to
>say more without knowing numbers of users/activity etc.
>
>
>

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Dirk Lutzebäck 2004-04-15 12:10:01 Toooo many context switches (maybe SLES8?)
Previous Message pginfo 2004-04-15 10:59:04 Re: [ SOLVED ] select count(*) very slow on an already