Так в том то и дело, что поднимаясь от 8

Question

Так в том то и дело, что поднимаясь от 8

к 6, мне не нужен индекс, т.к. я беру parent_id, и ищу все записи где id = parent_id, т.е. используется индекс PK. Но тогда, как посчитать глубину вложенности? Если я выбираю комменты, где parent_id IS NOT NULL, значит эти комменты уже имеют какую-то вложенность. Может они имеют вложенность 3? А может 7? Это становится известно только если мы пойдем итеративно с корня, каждый раз увеличивая счетчик.

Вот схема и запрос: https://pastebin.com/YMQfNWEW
Вот explain analyze: https://pastebin.com/vdiZ0vp8

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

В этом запросе нужно добавить индекс по post_id, community_id, parent_id NULLS FIRST, после этого эксплейн становится таким: https://pastebin.com/XWCirwSv

Если добавить индекс parent_id, эксплейн становится уже таким: https://pastebin.com/W5zJqEjD

Я вот и хочу уйти от индекса parent_id, но тогда нужно сам запрос переписать, и как высчитывать depth, если мы начинаем с заранее неизвестного уровня?

#backend #devops #pgsql #programming #russian

0

17.03.2020

3 ответов

14 просмотров

Владимир

Смотрели ltree, попробуйте очень снимает боль с деревьями, если аккуратно использовать.

0

17.03.2020

Yaroslav Schekin

> Это становится известно только если мы пойдем итеративно с корня, каждый раз увеличивая счетчик. Разве вложенность — это не длина пути от листа / узла к корню? И, соответственно, какая разница, откуда идти? Если идёте от листа — просто "разворачиваете" номера, да и всё... или я чего-то не вижу? (Планы не смотрел, т.к. они могут и не относиться к делу, с учётом вышенаписанного.)

0

17.03.2020

Виктор Ткаченко · Accepted Answer

Виктор Ткаченко

Зачем эти все сложности, собирайте в нужную структуру бэкендом, тк в любом случае это придется делать

0

17.03.2020

172 похожих чатов

Так в том то и дело, что поднимаясь от 8

3 ответов

Похожие вопросы