Postgresql запрос на выборку занимает много времени

Question

У меня есть таблица с именем events в моей базе данных Postgresql 9.5.И в этой таблице около 6 миллионов записей.

Я выполняю запрос select count(event_id) from events.Но этот запрос занимает 40 секунд.Это очень долгое время для базы данных.Мое event_id поле таблицы является первичным ключом и проиндексировано.Почему это занимает очень много времени?(Сервер Ubuntu VM на VMware имеет 4 CPU)

Объясните:

"Aggregate  (cost=826305.19..826305.20 rows=1 width=0) (actual time=24739.306..24739.306 rows=1 loops=1)"
"  Buffers: shared hit=13 read=757739 dirtied=53 written=48"
"  ->  Seq Scan on event_source  (cost=0.00..812594.55 rows=5484255 width=0) (actual time=0.014..24087.050 rows=6320689 loops=1)"
"        Buffers: shared hit=13 read=757739 dirtied=53 written=48"
"Planning time: 0.369 ms"
"Execution time: 24739.364 ms"

Answer 1

Есть несколько факторов, играющих большую роль в решении PostgreSQL о том, как выполнять count(), но, во-первых, столбец, который вы используете внутри функции count, не имеет значения.На самом деле, если вам не нужен счет DISTINCT, придерживайтесь count(*).

. Вы можете попробовать следующее, чтобы запустить сканирование только по индексу:

SELECT count(*) FROM (SELECT event_id FROM events) t;

..Если это все равно приводит к последовательному сканированию, то, скорее всего, индекс не намного меньше самой таблицы.Чтобы по-прежнему видеть, как будет выполняться сканирование только по индексу, вы можете принудительно выполнить его с помощью:

SELECT count(*) FROM (SELECT event_id FROM events ORDER BY 1) t;

ЕСЛИ это не намного быстрее, вам также следует подумать об обновлении PostgreSQL по крайней мере до версии 9.6, котораявводит параллельное последовательное сканирование , чтобы ускорить эти вещи.

Кроме того, вы можете добиться значительного ускорения, выбирая из множества методов, чтобы обеспечить подсчет, который в значительной степени зависит от вашего варианта использования и ваших требований:

• Более быстрый подсчет PostgreSQL

И последнее, но не менее важное: всегда предоставляйте вывод расширенного объяснения в виде уже рекомендованного @a_horse_with_no_name, например:

EXPLAIN (ANALYZE, BUFFERS) SELECT count(event_id) FROM events;