Очень высокая стоимость для нижнего предела LIMIT/высокого смещения

У меня очень большой стол с продуктами. Мне нужно выбрать несколько продуктов с очень большим смещением (пример ниже). Руководство Postgresql по индексам и производительности предлагает создать индекс для столбца, который используется ORDER BY + возможные условия. Все персиковое, никакой сорт не используется. но для высоких значений смещения LIMIT обходится очень дорого. Кто-нибудь знает, что может быть причиной этого?

Следующий запрос может выполняться в течение нескольких минут.

Indexes:
"product_slugs_pkey" PRIMARY KEY, btree (id)
"index_for_listing_by_default_active" btree (priority DESC, name, active)
"index_for_listing_by_name_active" btree (name, active)
"index_for_listing_by_price_active" btree (master_price, active)
"product_slugs_product_id" btree (product_id)

EXPLAIN SELECT * FROM "product_slugs" WHERE ("product_slugs"."active" = 1) ORDER BY product_slugs.name ASC LIMIT 10 OFFSET 14859;
                                                       QUERY PLAN                                                        
-------------------------------------------------------------------------------------------------------------------------
 Limit  (cost=26571.55..26589.43 rows=10 width=1433)
   ->  Index Scan using index_for_listing_by_name_active on product_slugs  (cost=0.00..290770.61 rows=162601 width=1433)
         Index Cond: (active = 1)
(3 rows)

postgresql sql performance explain
person Marcin Raczkowski    schedule 18.01.2011    source источник

Ответы (1)


arrow_upward
5
arrow_downward

Имеющийся здесь индекс index_for_listing_by_name_active мало чем поможет, поскольку продукты в результирующем наборе не обязательно будут непрерывными в индексе. Попробуйте создать условный индекс по имени только для тех продуктов, которые активны:

CREATE INDEX index_for_listing_active_by_name
  ON product_slugs (name)
  WHERE product_slugs.active = 1;
person pmdboi    schedule 18.01.2011
comment
Пока выглядит хорошо, оставлю оба на сегодня, а завтра посмотрим. Спасибо большое! - person Marcin Raczkowski; 19.01.2011
comment
приятно видеть, что кто-то помнит, что условные индексы существуют, вместо того, чтобы просто сказать, чтобы изменить порядок столбцов индекса :) - person araqnid; 19.01.2011
comment
Я попытался изменить порядок столбцов в тестовой базе данных, и это не помогло — на самом деле, все стало значительно хуже. Я не уверен, что это была за история, но я ожидал, что она поможет. - person pmdboi; 19.01.2011
comment
Я много экспериментировал с индексами. На самом деле я пробовал условные индексы раньше, и они, похоже, не помогали, но после этого я изменил структуру запроса, и теперь они просто сорвали джекпот. Во всяком случае изменение порядка раньше не помогало, также актив не очень избирательный 80% товаров активны. - person Marcin Raczkowski; 19.01.2011