Почему Postgresql такой медленный?

Question

[Анатолий Сидоров]

Добрый день!
В интернете множество хвалебных отзывов о постгресе, у всех все хорошо и здорово, таблицы с миллиардами данных и пр.
В действительности же мы на данный момент имеем таблицу на 1.5 миллиона записей статистики, обычный запрос на count(*) выполняется 0.700 мс.

[SQL] EXPLAIN ANALYSE select count(*) from table

Aggregate  (cost=174099.68..174099.69 rows=1 width=8) (actual time=787.417..787.418 rows=1 loops=1)
  ->  Seq Scan on table (cost=0.00..170511.54 rows=1435254 width=0) (actual time=0.444..637.771 rows=1435107 loops=1)
Planning time: 0.110 ms
Execution time: 787.479 ms

[SQL] EXPLAIN ANALYSE select count(*) from table where user_id=114
Aggregate  (cost=166624.17..166624.18 rows=1 width=8) (actual time=482.791..482.792 rows=1 loops=1)
  ->  Bitmap Heap Scan on table (cost=2919.96..166234.64 rows=155811 width=0) (actual time=46.828..463.465 rows=156944 loops=1)
        Recheck Cond: (user_id = 114)
        Rows Removed by Index Recheck: 153189
        Heap Blocks: exact=39222 lossy=26507
        ->  Bitmap Index Scan on idx_user_id  (cost=0.00..2881.01 rows=155811 width=0) (actual time=36.766..36.766 rows=156944 loops=1)
              Index Cond: (user_id = 114)
Planning time: 0.242 ms
Execution time: 483.520 ms

И это ведь простой подсчет кол-ва, а ведь требуется еще и агрегация отдельных столбцов, и джоины, и дистинкты, и еще много много чего.
Что мы упускаем? Нам просто нужно уметь быстро отфильтровать большой объем данных по заданной дате и пользователю. Партиционирование только усугубляет ситуацию, вероятно слишком малый объем данных.

UPD. Самый простой пример. Если миллион записей формата UUID, user_id, date. 95% запросов на select - это фильтр по user_id + date between(start, end). Что поможет в этом случае? Сейчас стоит btree-индекс на dt + user_id.

Заранее спасибо.

Comments

[Philipp]

Если вы хотите, чтобы быстро работало, используйте MariaDB или MongoDB, если задача позволяет.
Postgre подойдет для сложной аналитики и сложной БД, хранимок и т.д.

Answer 1

[Артём Клименко]

По поводу медленного COUNT на всю таблицу вам написали, а вот второй запрос "по нормальному" должен отрабатывать мгновенно, при условии что постгрес правильно настроен.

Вы случайно не используете настройки по умолчанию (а они там такие чтоб работало даже на калькуляторе)?
есди да то советую postgresql.leopard.in.ua там какраз новая версия недавно вышла.

Comments

[Анатолий Сидоров]

Проштрудировал ее за последние дни, по pgtune настроил, прирост если и есть, то копейки.

Answer 2

[Александр Аксентьев]

https://wiki.postgresql.org/wiki/Slow_Counting

Answer 3

[terrier]

Recheck Cond: (user_id = 114)
Rows Removed by Index Recheck: 153189
Heap Blocks: exact=39222 lossy=26507

У вас делается повторная проверка этого самого условия и она действительно отфильтровывает значительное количество строк. Long story short - вам не хватает work_mem, повысьте.

Answer 4

[thyratr0n]

Первый запрос не использует индекс. Похоже, что у таблицы нет PRIMARY KEY.
Второй запрос тоже не понятный. Похоже, что user_id содержится в комплексном индексе, типа (user_type, user_id), и т.к. не задействуется первое поле в запросе, то запрос тормозит.

Нужен DDL таблицы - без него это все напоминает гадание на кофейной гуще.

Answer 5

[Андрей Шишкин]

"Почему Postgresql такой медленный?"

Вы просто не умеете его готовить.

Answer 6

[Макс]

а сделайте ка EXPLAIN (ANALYSE, BUFFERS) ...