Долгие запросы к таблице

kvadratik
Дата: 20.07.2004 16:55:06
Прошу прощения за, возможно, глупый вопрос, но всё же..

Посылаю запрос
SELECT COUNT(*) FROM users; 
370 строк - запрос выполнялся больше 20 секунд.

Запрос
SELECT COUNT(*) FROM account; 
283406 строк - время выполнения 12 секунд.

Пробовал сделать
VACUUM users
&
VACUUM ANALYZE users
.
Похоже, что помогло, но очень незначительно.

Подскажите в чём дело.
Заранее благодарю.
Эридан
Дата: 20.07.2004 16:58:35
Во-первых, сделай VACUUM FULL, во-вторых, если результат запроса не сильно критичен - попробуй к примеру SELECT count(*) FROM users WHERE id>0, где id - pimary key. Суть та же, но это позволяет использовать индекс, и в некоторых запущенных случаях позволяет повысить производительность.
kvadratik
Дата: 20.07.2004 18:09:02
Спасибо, помогло. Всё отлично работает :)
vis
Дата: 20.07.2004 19:17:27
select count(<primary_key>) from <table> тоже покатит
Эридан
Дата: 21.07.2004 03:31:35
vis
select count(<primary_key>) from <table> тоже покатит


Мне кажется, нет, поскольку при вычислении агрегатных функций индексы не используются.
vis
Дата: 21.07.2004 09:42:09
Эридан
vis
select count(<primary_key>) from <table> тоже покатит


Мне кажется, нет, поскольку при вычислении агрегатных функций индексы не используются.


проверил... был неправ :)
таки не работает индекс для count()
Эридан
Дата: 21.07.2004 12:06:51
Самое смешное, что предложенный мной способ (WHERE id>0) тоже не всегда цепляет индексы. Зависит от того, как лягут звезды для оптимизатора.

Да и вообще не дело это. Надо безо всяких условий писать :)

В свое время я связывался с одним из разработчиков Postgres, вот цитата из письма:

Мой вопрос:
> Добрый день, Теодор.
>
> Скажи пожалуйста, как рекомендуется вычислять точное количество > записей в таблице?
>
> Согласно документу
> http://www.postgresql.org/docs/7.4/interactive/functions-aggregate.html
> насколько я понял, есть определенные проблемы с вычислением
>
> select count(*)
> from some_table

Ответ Теодора Сигаева:

> Так и рекомендуется. Проблемы есть только в быстродействии. Но для
> быстродействия стоит написать триггера на insert & delete, которые щелкают
> счетчик в отдельной таблице).

> Проблемы с быстродействием заключаются в MVCC (multi version concurrence
> control) - в зависимости от настроек transaction isolation level и текущих
> транзакций рез-тат может быть разный. Поэтому только sequence scan гарантирует
> целостность count(*).