|
Модераторы: LSD |
|
polin11 |
|
||||||
Шустрый Профиль Группа: Участник Сообщений: 122 Регистрация: 6.6.2015 Репутация: нет Всего: нет |
Иcпользую PostreSQL, есть рекурсивный запрос в таблице Document для получение записей вниз по иерархии, идентификатор в таблице @Document.
Поле Hierarchy ссылка на идентификатор родительской записи.
План выполнения запроса:
Хочется избавиться от seq scan Есть индекс по полю Hierarchy - он не используется Есть составной индекс (Hierarchy, @Document ) - он не используется сделал индекс
он используется, но перестает использоваться когда добавляется новое поле в SELECT, приходится добавлять новое поле в индекс. Как бы создать индекс, на который не влиял бы набор полей в SELECT? |
||||||
|
|||||||
Akina |
|
|||
Советчик Профиль Группа: Модератор Сообщений: 20570 Регистрация: 8.4.2004 Где: Зеленоград Репутация: 3 Всего: 453 |
Никак. Единственная точка, где может использоваться индекс - это рекурсивная часть CTE. Причём только для исходной таблицы, но не для CTE-таблицы. Там используется единственное поле "Document"."Hierarchy". Однако статистика не позволяет предсказать селективность этого индекса в рекурсивном запросе - поэтому индекс по этому полю не будет использоваться. Соответственно единственная возможность хоть как-то использовать индекс в этом запросе - использовать покрывающий индекс. Но добавление поля в выходной набор приводит к тому, что индекс перестаёт быть покрывающим. Подумай о дополнительном поле, хранящем полный характеристический путь записи. Да, таблица станет пухлее. появятся проблемы с поддержанием целостности - зато запрос выборки детей будет летать, ибо рекурсия на такой структуре нафиг не нужна... Ну или используй любую другую систему хранения, заточенную именно не только под хранение дерева, но и под и операции с ним. -------------------- О(б)суждение моих действий - в соответствующей теме, пожалуйста. Или в РМ. И высшая инстанция - Администрация форума. |
|||
|
||||
1 Пользователей читают эту тему (1 Гостей и 0 Скрытых Пользователей) | |
0 Пользователей: | |
« Предыдущая тема | PostgreSQL | Следующая тема » |
|
По вопросам размещения рекламы пишите на vladimir(sobaka)vingrad.ru
Отказ от ответственности Powered by Invision Power Board(R) 1.3 © 2003 IPS, Inc. |