Re: Grave performance issues...

Поиск
Список
Период
Сортировка
От caldodge@fpcc.net (Calvin Dodge)
Тема Re: Grave performance issues...
Дата
Msg-id ca6275f0.0201011501.5bb87758@posting.google.com
обсуждение исходный текст
Ответ на Grave performance issues...  ("Ztream" <ztream@highrad.org>)
Список pgsql-general
"Ztream" <ztream@highrad.org> wrote in message news:<a0fr1a$1eil$1@news.tht.net>...
> Distribution size of 600 rows! Also, neither of the other two tables
> referenced contained more than 30 rows.
>
> *2
> Even when the involved tables are freshly vacuumed (and vacuum analyzed),
> the above query using the data amount from (*1) takes about 4 seconds to

That time does sound REALLY excessive for the quantity of data
involved.

Have you tried "EXPLAIN" to see how PostgreSQL is implementing the
query?

Are there indexes on UserID in "Data" and "GroupMember"?

Have you tried using a temporary table as an in-between stage?
Something like:

CREATE TEMPORARY TABLE stats AS SELECT ItemID, Grade,
WeightGroupID,COUNT(*)as statcount FROM Data INNER JOIN GroupMember ON
Data.UserID = GroupMember.UserID GROUP BY 1,2,3

UPDATE distribution SET value = (SELECT statcount FROM stats WHERE
ItemID = Distribution.ItemID AND Grade = Distribution.Grade AND
WeightGroupID = Distribution.WeightGroupID)



Have you tried watching the output of "vmstat 1", to see if excessive
disk I/O or swapping is the culprit?

Would you consider emailing me a pg_dump of the affected tables, so I
can try it on a computer here to see if the problem is in your SQL or
in your server?

Inquiring minds want to know ...

Calvin Dodge
Certified Linux Bigot(tm)

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

Предыдущее
От: Chris Albertson
Дата:
Сообщение: Re: Installing postgresql on Win2K
Следующее
От: Chris Albertson
Дата:
Сообщение: Re: Grave performance issues...