Модераторы: LSD
  

Поиск:

Ответ в темуСоздание новой темы Создание опроса
> Создать индекс для рекурсивного запроса 
:(
    Опции темы
polin11
Дата 25.1.2021, 22:26 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Шустрый
*


Профиль
Группа: Участник
Сообщений: 122
Регистрация: 6.6.2015

Репутация: нет
Всего: нет



Иcпользую PostreSQL, есть рекурсивный запрос в таблице Document для получение записей вниз по иерархии, идентификатор в таблице @Document.
Поле Hierarchy ссылка на идентификатор родительской записи.
Код

EXPLAIN (ANALYZE,BUFFERS)
        WITH  RECURSIVE 
                hier_down AS(
                    SELECT
                       h."@Document",
                       h."Hierarchy",
                       h."Hint"
                       FROM "Document" h
                       WHERE
                          "@Document" = 13
                    UNION all
                    SELECT
                        "Document" ."@Document",
                         "Document" ."Hierarchy",
                         "Document"."Hint"
                    FROM hier_down, "Document" 
                    WHERE   "Document"."Hierarchy" =  hier_down."@Document"
                )
SELECT *
FROM hier_down



План выполнения запроса:
Код

"CTE Scan on hier_down  (cost=783.59..861.41 rows=3891 width=44) (actual time=0.008..0.748 rows=5 loops=1)"
"  Buffers: shared hit=281"
"  CTE hier_down"
"    ->  Recursive Union  (cost=0.28..783.59 rows=3891 width=76) (actual time=0.007..0.745 rows=5 loops=1)"
"          Buffers: shared hit=281"
"          ->  Index Scan using "pDocument" on "Document" h  (cost=0.28..8.29 rows=1 width=76) (actual time=0.006..0.006 rows=1 loops=1)"
"                Index Cond: ("@Document" = 13110)"
"                Buffers: shared hit=3"
"          ->  Hash Join  (cost=0.33..69.75 rows=389 width=76) (actual time=0.044..0.143 rows=1 loops=5)"
"                Hash Cond: ("Document"."Hierarchy" = hier_down_1."@Document")"
"                Buffers: shared hit=278"
"                ->  Seq Scan on "Document"  (cost=0.00..62.66 rows=766 width=76) (actual time=0.003..0.061 rows=766 loops=5)"
"                      Buffers: shared hit=275"
"                ->  Hash  (cost=0.20..0.20 rows=10 width=4) (actual time=0.002..0.002 rows=1 loops=5)"
"                      Buckets: 1024  Batches: 1  Memory Usage: 9kB"
"                      ->  WorkTable Scan on hier_down hier_down_1  (cost=0.00..0.20 rows=10 width=4) (actual time=0.000..0.000 rows=1 loops=5)"
"Planning time: 0.336 ms"
"Execution time: 0.786 ms"



Хочется избавиться от seq scan
Есть индекс по полю Hierarchy - он не используется
Есть составной индекс (Hierarchy, @Document ) - он не используется

сделал индекс
Код

CREATE INDEX "Hier"
ON "Document" USING btree
("Hierarchy" NULLS LAST, "@Document" NULLS LAST, "Hint" NULLS LAST);

он используется, но перестает использоваться когда добавляется новое поле в SELECT, приходится добавлять новое поле в индекс.

Как бы создать индекс, на который не влиял бы набор полей в SELECT?
PM MAIL   Вверх
Akina
Дата 26.1.2021, 07:53 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Советчик
****


Профиль
Группа: Модератор
Сообщений: 20570
Регистрация: 8.4.2004
Где: Зеленоград

Репутация: 3
Всего: 453



Цитата(polin11 @  25.1.2021,  23:26 Найти цитируемый пост)
Как бы создать индекс, на который не влиял бы набор полей в SELECT?

Никак.

Единственная точка, где может использоваться индекс - это рекурсивная часть CTE. Причём только для исходной таблицы, но не для CTE-таблицы. Там используется единственное поле "Document"."Hierarchy". Однако статистика не позволяет предсказать селективность этого индекса в рекурсивном запросе - поэтому индекс по этому полю не будет использоваться.

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

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

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


--------------------
 О(б)суждение моих действий - в соответствующей теме, пожалуйста. Или в РМ. И высшая инстанция - Администрация форума.

PM MAIL WWW ICQ Jabber   Вверх
  
Ответ в темуСоздание новой темы Создание опроса
1 Пользователей читают эту тему (1 Гостей и 0 Скрытых Пользователей)
0 Пользователей:
« Предыдущая тема | PostgreSQL | Следующая тема »


 




[ Время генерации скрипта: 0.1069 ]   [ Использовано запросов: 21 ]   [ GZIP включён ]


Реклама на сайте     Информационное спонсорство

 
По вопросам размещения рекламы пишите на vladimir(sobaka)vingrad.ru
Отказ от ответственности     Powered by Invision Power Board(R) 1.3 © 2003  IPS, Inc.