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

Поиск
Список
Период
Сортировка
От Jeff
Тема Re: [ SOLVED ] select count(*) very slow on an already
Дата
Msg-id 954A8D6A-907B-11D8-8E5D-000D9366F0C4@torgo.978.org
обсуждение исходный текст
Ответ на Re: [ SOLVED ] select count(*) very slow on an already  (Rajesh Kumar Mallah <mallah@trade-india.com>)
Список pgsql-performance
On Apr 16, 2004, at 4:23 AM, Rajesh Kumar Mallah wrote:

>
>
>  I am running an update on the same table
>
>  update rfis set inquiry_status='APPROVED' where inquiry_status='a';
>
>  Its running for past 20 mins. and top output is below.
>  The PID which is executing the query above is 6712. Can anyone
>  tell me why it is in an uninterruptable sleep and does it relate
>  to the apparent poor performance? Is it problem with the disk
>  hardware. I know at nite this query will run reasonably fast.
>

I've had this problem recently.  The problem is simply that the disk
cannot keep up.  Most likely you don't see it at night because traffic
is lower.  There are only 2 solutions: 1. get more disks 2. write to
the db less

The machine I was running on had a single(!) disk.  It was a quad xeon
so there was plenty of cpu.   I'd see 8-9 processes stuck in the "D"
state.  Doing a simple ls -l somefile would take 10-15 seconds and of
course, db performance was abysmal.

I had a lowly P2 with a few disks in it that was able to run circles
around it for the simple fact the machine was not waiting for disk.
Again, proof that disk is far more important than CPU in a db.

good luck.

--
Jeff Trout <jeff@jefftrout.com>
http://www.jefftrout.com/
http://www.stuarthamm.net/


В списке pgsql-performance по дате отправления:

Предыдущее
От: Christopher Browne
Дата:
Сообщение: Re: Long running queries degrade performance
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Horribly slow hash join