Запрос PostGIS не использует Gist-индекс при выполнении ST_DUMP(ST_UNION

Мой запрос:

DROP TABLE IF EXISTS tmp;
CREATE TEMP TABLE tmp AS SELECT *, ST_BUFFER(the_geom::GEOGRAPHY, 3000)::GEOMETRY AS buffer FROM af_modis_master LIMIT 20000;
CREATE INDEX idx_tmp_the_geom ON tmp USING gist(buffer); 
EXPLAIN SELECT (DUMP(ST_UNION(buffer))).path[1], (DUMP(ST_UNION(buffer))).geom FROM tmp;

Вывод из ОБЪЯСНЕНИЯ:

Aggregate  (cost=1705.52..1705.54 rows=1 width=32)
  ->  Seq Scan on tmp  (cost=0.00..1625.01 rows=16101 width=32)

Seq Scan означает, что он не использует индекс, верно? Почему бы и нет?

(Этот вопрос был впервые опубликован здесь: https://gis.stackexchange.com/questions/51877/postgis-query-not-using-gist-index-when-doing-a-st-dumpst-union.. Извинения за репост, но сообщество здесь гораздо активнее, так что, возможно, быстрее дадут ответ.)

ОБНОВЛЕНИЕ: Даже добавление предложения where, которое фильтрует на основе буфера, вызывает сканирование Seq:

ANALYZE tmp;
EXPLAIN SELECT (DUMP(ST_UNION(buffer))).path[1], (DUMP(ST_UNION(buffer))).geom FROM tmp WHERE ST_XMIN(buffer) = 0.0;

person Ries    schedule 14.02.2013    source источник
comment
Обновляли ли вы статистику перед выполнением запроса?   -  person Szymon Lipiński    schedule 14.02.2013
comment
Нет, но когда я делаю ANALYZE tmp; сразу после создания индекса я все еще получаю Seq Scan от EXPLAIN.   -  person Ries    schedule 14.02.2013
comment
Похоже, вы хотите запустить st_union для всех строк в таблице. Скорее всего, Postgres считает, что использование индекса не сделает его быстрее. Индекс будет использоваться, когда вы сначала будете выбирать некоторые геометрии, в предложении where.   -  person Szymon Lipiński    schedule 14.02.2013
comment
Хорошо, имеет смысл. Интересно, что выполнение шага анализа, по-видимому, улучшает время выполнения с ~ 15 до ~ 11 секунд.   -  person Ries    schedule 14.02.2013
comment
Я попытался проверить вашу гипотезу, добавив предложение where: ... FROM tmp WHERE ST_XMIN(buffer) = 0.0; Я все еще получаю Seq Scan от объяснения.   -  person Ries    schedule 15.02.2013
comment
не переписываться: gis.stackexchange.com/questions/51877/   -  person Mike T    schedule 17.02.2013


Ответы (1)


Такой запрос, как у вас, никогда не будет использовать индекс. Для этого потребуется заменить значительный произвольный дисковый ввод-вывод (возможно, даже в дополнение к обычному дисковому вводу-выводу) на сканирование таблицы.

По сути, вы не выбираете критерии, поэтому индекс будет медленнее, чем просто извлечение данных с диска в физическом порядке и их обработка.

Теперь, если вы вытащите только одну строку с условием where, с которым может помочь ваш индекс, вы можете обнаружить, что он может использовать индекс или нет, в зависимости от того, насколько велика таблица. Очень маленькие таблицы никогда не будут использовать индексы, потому что дополнительный произвольный дисковый ввод-вывод никогда не будет выигрышным. Помните, что ни один план запроса не превосходит последовательное сканирование одной страницы....

person Chris Travers    schedule 26.04.2013