Почему IS TRUE не использует соответвующий index?

Question

[lightseeker]

Есть запрос который использует индекс столбца при выполенн

EXPLAIN SELECT COUNT(*) as count FROM users WHERE verified;

Aggregate  (cost=110125.36..110125.37 rows=1 width=8)
  ->  Index Only Scan using users_idx_verified on users  (cost=0.41..109977.59 rows=59109 width=0)

Когда добавляется IS TRUE, план координально меняется и перестает использовать индекс

EXPLAIN SELECT COUNT(*) as count FROM users WHERE verified IS TRUE

Finalize Aggregate  (cost=200268.02..200268.03 rows=1 width=8)
  ->  Gather  (cost=200267.81..200268.02 rows=2 width=8)
        Workers Planned: 2
        ->  Partial Aggregate  (cost=199267.81..199267.82 rows=1 width=8)
              ->  Parallel Seq Scan on users  (cost=0.00..199206.23 rows=24629 width=0)
                    Filter: (verified IS TRUE)

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

Comments

[mayton2019]

А где работает быстрее? С практической точки зрения. Если не смотреть на costs.

[lightseeker]

mayton2019, Результат кешируется, не могу точно сказать. Да и не важно где быстрее..если в первом варианте - то почеми второй не использует индекс, если во втором - почему первый не использует sequence scan раз уж это намного эффективнее

[lightseeker]

mayton2019, Но по идее должен быть быстрее первый вариант, так как на таблице около 10 миллион строк, verified=true около 70 тысяч, так что здесь явно нужна работа индекса

[lightseeker]

Dr. Bacon, ну тогда зачем в первом варианте используется индекс?

[mayton2019]

lightseeker, современные оптимизаторы не используют Rule-Base подход. Они смотрят в цифры статистик. А вообще индекс по булевому полю - это считается зашквар. Ну .. по крайней мере он низкокардинальный. А это значит неэффективный. Вообще я-бы посчитал сколько в таблице True/False/Null и потом уже рассуждал бы на тему эффективности.

Ну и почитай что тебе Доктор Бекон пишет.

[lightseeker]

Dr. Bacon, сорри, у не тот запрос под руку попался ))) уже исправил

[Константин Цветков]

Индексы в PostgreSQL.

Answer 1

[Dimonchik]

современные оптимизаторы не используют Rule-Base подход. Они смотрят в цифры статистик. А вообще индекс по булевому полю - это считается зашквар. Ну .. по крайней мере он низкокардинальный. А это значит неэффективный. Вообще я-бы посчитал сколько в таблице True/False/Null и потом уже рассуждал бы на тему эффективности.

mayton2019, это в ответ надо

более чем уверен, что в первом запросе когда not null дефакто, базе проще откинуть биты и взять количество, из индекса, раз уж он есть

во втором же - приходися смотреть в индекс и все равно делать сравнение с условием, видимо, разрабами считается в этом случае не использовать индекс, т.к. обычно запросы не Count а Select что-то, а это с индексом уже два действия: пробег по индексу и адресация к полю выборки, проще сразу пробежаться по полям

+ хз что там сверху наворочено

Comments

[mayton2019]

Вы уже написали в ответы. Пускай тут и лежит. Кроме того автор набокапорил с таблицами и поэтому я считал что ответ писать еще рано. Ощущение незаконченного дела тык-скыть.