>> 4)Что показывает SELECT pg_relation_size('accounts');
>
> pg_relation_size
> ------------------
> 353107968
350mb для таблицы в 1700 записей это как то грустно.
Таблица распухла раз в 100-1000 (точнее будет ясно после vacuum full)
сканировать 350mb всегда медленно (даже если это на 99% пустое место).
>> 6)Нету ли старых открытых транзакций (более 24х часов скажем)?
>
> Была одна. (как могло влиять ?)
> Закрыл. (что надо сделать чтобы это возымело эффект?)
Открытая транзакция не дает возможность базе после vacuum повторно использовать пустое место.
Так что если транзакция длинная а поток обновлений большой то таблица может пухнуть до бесконечности.
Советы:
1)Настроить autovacuum (ночной vacuum analyze не самое удачное решение)
(http://www.postgresql.org/docs/8.2/interactive/routine-vacuuming.html#AUTOVACUUM)
и отключить ночные vacuum
2)любой ценой избегать длинных (более 1-2-3 часов транзакций)
Конкретно с этой таблицей на нее надо сделать:
vacuum full analyze accounts;
после чего ее размер вернется к норме и скорость count(*) станет выше.
(только надо не забывать что vacuum full блокирует любые операции с таблицей включая select и может работать заметное
время).
>>> Подскажите пожалуйста какие ошибки
>>> (можетбыть в настройках постгреса)
>>> могли привести вот к такому эффекту:
>>>
>>> personal=# explain ANALYZE SELECT count(*) from accounts;
>>>
>>> QUERY PLAN
>>> -------------------------------------------------------------
>>> Aggregate (cost=43126.25..43126.26 rows=1 width=0) (actual
>>> time=975.628..975.628 rows=1 loops=1)
>>> -> Seq Scan on accounts (cost=0.00..43121.80 rows=1780 width=0)
>>> (actual time=0.122..974.565 rows=1782 loops=1)
>>> Total runtime: 975.687 ms
>>>
>>>
>>> personal=# SELECT count(*) from accounts;
>>>
>>> count
>>> -------
>>> 1782
>>>
>>>
>>> Всего-то 1782 записи ! и такая огромная цена.
>>> и реальное время выполнения тоже неприемлемое.
>>>
>>> vacuum analyze делается каждую ночь
>>>
>>
>>
>
>
--
Maxim Boguk