Если PostgreSQL count (*) всегда медленно, как разбивать сложные запросы?

Если PostgreSQL count(*) всегда медленно, как разбивать сложные запросы?

Создание триггеров не кажется хорошим решением, поскольку в этом случае у нас много страниц (например, разные категории, фильтры и т.д.).

Что делать, если VACUUM/VACUUM ANALYZE/ANALYZE/VACUUM FULL не помогает? Каковы наилучшие методы использования count(*) с postgresql?

Ответы

Ответ 1

Вы прочитали заголовок этой статьи?

Обратите внимание, что следующая статья относится только к версиям PostgreSQL до 9.2. Сканирование только по индексу теперь реализовано.

Используйте 9.2, и вы, как правило, обнаружите, что получаете гораздо лучшие результаты. Подробнее читайте только для просмотра страниц вики.

Тем не менее, в старых версиях с использованием LIMIT и OFFSET обычно работает нормально. Вы можете оценить rowcounts (и, следовательно, pagecounts), используя статистику таблицы, если вы не возражаете против вариации. См. "Оценка количества строк" ​​в статье, которую вы уже связали с.

Разбиение на страницы с использованием LIMIT и OFFSET равно, IMO, анти-шаблон в любом случае. Много времени вы можете перефразировать свой код разбивки на страницы, чтобы он использовал sort_column > 'last_seen_value' LIMIT 100, то есть избегал смещения. Иногда это может привести к очень высокой производительности.

Ответ 2

Если вы делаете таблицу SELECT count (*) FROM и включаете статистику pg, вы можете использовать нижний пример, который в этом случае идет от 13 мс до 0,05 мс.

SELECT count(*) FROM news;

26171

EXPLAIN ANALYZE SELECT count(*) FROM news;

Общая продолжительность выполнения: 13.057 мс

SELECT reltuples::bigint AS count FROM pg_class WHERE oid = 'public.news'::regclass;

26171

EXPLAIN ANALYZE SELECT reltuples::bigint AS count FROM pg_class WHERE oid = 'public.news'::regclass;

Общая продолжительность выполнения: 0,053 мс