Postges делает Seq Scan вместо Index Only Scan для очень простого SELECT x ... ORDER BY x - PullRequest
Новая
       50

Postges делает Seq Scan вместо Index Only Scan для очень простого SELECT x ... ORDER BY x

0 голосов
/ 16 ноября 2018

У меня есть таблица union_events с 17M строк и 102 столбцами в Postgres 10. Я запускаю команды: 

CREATE INDEX union_events_index ON temp_schema_to_delete.union_events(id)
ANALYZE temp_schema_to_delete.union_events
EXPLAIN SELECT id FROM temp_schema_to_delete.union_events ORDER BY id

и получаю следующие результаты: 

Sort  (cost=3614290.72..3658708.19 rows=17766988 width=4)
    Sort Key: id
    ->  Seq Scan on union_events  (cost=0.00..1474905.88 rows=17766988 width=4)

id - это не целое и не уникальное целочисленное поле.

Я ожидаю, что будет использован мой индекс, и мне не придется снова сортировать таблицу.

Я быстроtest: 

SELECT s INTO temp_schema_to_delete.test FROM generate_series(0, 10000000) AS s
CREATE INDEX test_index ON temp_schema_to_delete.test(s)
ANALYZE temp_schema_to_delete.test
EXPLAIN SELECT s FROM temp_schema_to_delete.test ORDER BY s

Получается: 

Index Only Scan using test_index on test  (cost=0.43..303940.15 rows=10000048 width=4)

Кажется, все в порядке.

Что не так с моей первой таблицей или запросом?Почему индекс по id не используется?

1 Ответ

0 голосов
/ 21 ноября 2018

Как и рекомендовал @joop, я сделал ВАКУУМ для таблицы.

Это привело к лучшему плану, который использует мой индекс.

Для меня все еще не ясно, как VACUUM мог помочь с представлением факта, что я создал эту таблицу, используя SELECT ... INTO TABLE, и не сделал никаких ОБНОВЛЕНИЙ или УДАЛЕНИЙ.

Было бы замечательно, если бы кто-то мог объяснить это в другом ответе, возможно, существует какое-то эффективное решение, чем ВАКУУМ.

...